Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <39CB6F43.B5E65296@element-14.com>
Date: Fri, 22 Sep 2000 15:40:03 +0100
From: Nigel Wetten <nigel DOT wetten AT element-14 DOT com>
X-Mailer: Mozilla 4.72 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: cygwin AT sourceware DOT cygnus DOT com
Subject: dllhelpers-0.2.5/c++ doesn't work
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Without touching the source, compiling the c++ example leads to warnings
about not being able to find __cygwin_dll_entry AT 12. When executed, the
binary puts a message box saying
"The dynamic link library cxxdll.dll is not written correctly. The stack
pointer has been left in an inconsistent state. The entrypoint should be
declared as WINAPI or STDCALL" 
Effectively the program cannot run.

Adding the following to dllclass.cc to try to address the above problem:

extern "C" {

#include <windows.h>

  int WINAPI
  _cygwin_dll_entry(HANDLE h, DWORD reason, void *foo)
  {
    return 1;
  }
}

solves the build warnings. When run, the program produces the following
output:
Global integer variable = 5
DllClass 1 (Imported from DLL):
  virtual_method = 0
  non_virtual_method = 0
  instances = 0
DllClass 2 (Imported from DLL):
  virtual_method = 0
  non_virtual_method = 0
  instances = 0
DllClass (Local):
  virtual_method = 27
  non_virtual_method = 9
  instances = 1

The README file shows different output. The above is clearly the result
of a bug. In particular, with the latest cygwin net release, I am unable
to get constructors run on global objects. I'm guessing this is why
using iostreams in a dll leads to a crash.
Does anyone have a solution? Suggestions? 
Or perhaps the necessary build commands changed?

Nigel

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com