Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 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 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