DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 93EAE386F45A
Subject: Re: Using cygwin-dll with msvc-exe
To: cygwin AT cygwin DOT com
References: <00a401d64b9c$9958e6d0$cc0ab470$@gmail.com>
From: Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Autocrypt: addr=Brian DOT Inglis AT SystematicSw DOT ab DOT ca; prefer-encrypt=mutual;
 keydata=
 mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0
 LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA
 PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
 AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
 WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB
 BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5
 /lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
 IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
 RSyTY8X+AQ==
Organization: Systematic Software
Message-ID: <56b93fc2-1a64-4d53-5ce5-5038b263d251@SystematicSw.ab.ca>
Date: Fri, 26 Jun 2020 11:32:03 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.9.0
MIME-Version: 1.0
In-Reply-To: <00a401d64b9c$9958e6d0$cc0ab470$@gmail.com>
Content-Language: en-CA
Precedence: list
Reply-To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces AT cygwin DOT com>

On 2020-06-26 03:31, Kristian Ivarsson via Cygwin wrote:
> Our task is to use an own cygwin-gcc-dll imported and used in a msvc-exe
> (64-bit-system)
> According to https://cygwin.com/faq.html#faq.programming.msvc-gcc-objects it
> seems like it would be possible by doing it like
> https://cygwin.com/cygwin-ug-net/dll.html
> The msvc-exe compiles and links with no problems, but crashes during start
> up in runtime (as soon as there are any reference to the (extern "C")
> functions in the DLL (they aren't even called))
> We're linking agains the import .lib and using implicit loading (i.e. no
> LoadLibrary)
> The console output is:
> ...
>    $ /cygdrive/c/Repos/Trunk/Debug64/my_msvc_program.exe
>          0 [main] my_msvc_program (17392) child_copy: cygheap read copy
> failed, 0x180343408..0x18036E1D8, done 0, windows pid 17392, Win32 error 6
>        582 [main] my_msvc_program (17392)
> C:\Repos\Trunk\Debug64\my_msvc_program.exe: *** fatal error - ccalloc would
> have returned NULL
> ...
> A snippet from strace output is:
> ...
>      193    5437 [main] my_msvc_program (12608) fhandler_pipe::create:
> CreateFile: name \\.\pipe\cygwin-e022582115c10879-12608-sigwait
>      198    5635 [main] my_msvc_program (12608) fhandler_pipe::create: pipe
> write handle 0x130
>      171    5806 [main] my_msvc_program (12608) dll_crt0_0: finished
> dll_crt0_0 initialization
>    --- Process 12608 thread 2084 created
>     1050    6856 [sig] my_msvc_program (12608) wait_sig: entering ReadFile
> loop, my_readsig 0x12C, my_sendsig 0x130
>    --- Process 12608, exception c0000005 at 00000004a9e3b012
> ...
> I guess I'm experiencing the same issue as
> https://stackoverflow.com/questions/25787344/using-dll-compiled-with-cygwin-
> inside-visual-studio-2010 (it is using explicit loading of the DLL though)
> Just linking the dll works fine, but as soon as a symbol is referenced, it
> seems like the linker/loader make things end up in a weird way. The only odd
> thing I can see is that the loader (ldd) finds our dll before cygwin1.dll
> and thus our own dll is loaded before cygwin.dll
> So, should it be possible to use cygwin-gcc-built-dll:s in msvc-built-exe:s
> (or msvc-built-dll:s) ? If so, does anyone have a qualified idea of what
> might be missing/wrong in what we're doing ?

They have incompatible internal startup and runtime environments including stuff
like initialization, signal, and exit function handling (cygwin/newlib/gcc vs
Windows/APIs/VC) although Cygwin can build Windows-loadable dlls and
Windows-runnable exes and call Windows (system) dlls that don't depend on msvcrt.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple