* Using cygwin-dll with msvc-exe
@ 2020-06-26 9:31 sten.kristian.ivarsson
2020-06-26 17:13 ` Andrey Repin
2020-06-26 17:32 ` Brian Inglis
0 siblings, 2 replies; 6+ messages in thread
From: sten.kristian.ivarsson @ 2020-06-26 9:31 UTC (permalink / raw)
To: cygwin
Hi all
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 ?
Best regards,
Kristian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using cygwin-dll with msvc-exe
2020-06-26 9:31 Using cygwin-dll with msvc-exe sten.kristian.ivarsson
@ 2020-06-26 17:13 ` Andrey Repin
2020-06-30 7:19 ` Sv: " sten.kristian.ivarsson
2020-06-26 17:32 ` Brian Inglis
1 sibling, 1 reply; 6+ messages in thread
From: Andrey Repin @ 2020-06-26 17:13 UTC (permalink / raw)
To: Kristian Ivarsson via Cygwin, cygwin
Greetings, Kristian Ivarsson via Cygwin!
> Our task is to use an own cygwin-gcc-dll imported and used in a msvc-exe
> (64-bit-system)
I may be wrong (I'm not a developer in this case), but there's an inherent
problem with linking Cygwin DLL into native project.
Cygwin uses wholly different memory layout than what you'd normally see in
native apps.
This is because Cygwin has to support POSIX-mandated fork(2) semantics.
> 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
> ...
This is what happens when you mix different memory managers.
> 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 ?
> Best regards,
> Kristian
> --
> 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
--
With best regards,
Andrey Repin
Friday, June 26, 2020 19:54:36
Sorry for my terrible english...
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using cygwin-dll with msvc-exe
2020-06-26 9:31 Using cygwin-dll with msvc-exe sten.kristian.ivarsson
2020-06-26 17:13 ` Andrey Repin
@ 2020-06-26 17:32 ` Brian Inglis
2020-06-30 7:15 ` Sv: " sten.kristian.ivarsson
1 sibling, 1 reply; 6+ messages in thread
From: Brian Inglis @ 2020-06-26 17:32 UTC (permalink / raw)
To: cygwin
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.]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Sv: Using cygwin-dll with msvc-exe
2020-06-26 17:32 ` Brian Inglis
@ 2020-06-30 7:15 ` sten.kristian.ivarsson
2020-06-30 14:45 ` Brian Inglis
0 siblings, 1 reply; 6+ messages in thread
From: sten.kristian.ivarsson @ 2020-06-30 7:15 UTC (permalink / raw)
To: cygwin
[snip]
> 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.
What is interesting is that ldd on cygwin1.dll says it depends on
msvcrt.dll, but that might not be a problem ?
It seems like you could somehow fix it with this trick
https://cygwin.com/faq/faq.html#faq.programming.msvs-mingw (though I don't
really understand what difference it would make, because something seems to
be missing in the explanation (or more probably there's something I don't
understand;-) and it seems to be a bit cumbersome as well if you're having a
large product with a long lifetime)
In my honest opinion I think this disability to use cygwin-libraries from
windows-applications kind of limits some of cygwins purpose, but I do still
think cygwin is a great open source project ;-)
Best regards,
Kristian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Sv: Using cygwin-dll with msvc-exe
2020-06-26 17:13 ` Andrey Repin
@ 2020-06-30 7:19 ` sten.kristian.ivarsson
0 siblings, 0 replies; 6+ messages in thread
From: sten.kristian.ivarsson @ 2020-06-30 7:19 UTC (permalink / raw)
To: cygwin
[snip]
> > ...
> > $ /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 ...
>
> This is what happens when you mix different memory managers.
Well, I'm not even allocating anything or not even calling a single
function, but I guess that's irrelevant in this case ?
[snip]
Best regards,
Kristian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Using cygwin-dll with msvc-exe
2020-06-30 7:15 ` Sv: " sten.kristian.ivarsson
@ 2020-06-30 14:45 ` Brian Inglis
0 siblings, 0 replies; 6+ messages in thread
From: Brian Inglis @ 2020-06-30 14:45 UTC (permalink / raw)
To: cygwin
On 2020-06-30 01:15, Kristian Ivarsson via Cygwin wrote:
> [snip]
>
>> 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.
> What is interesting is that ldd on cygwin1.dll says it depends on
> msvcrt.dll, but that might not be a problem ?
That might not be accurate:
$ cygcheck cygwin1.dll
Found: C:\...\cygwin64\bin\cygwin1.dll
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
> It seems like you could somehow fix it with this trick
> https://cygwin.com/faq/faq.html#faq.programming.msvs-mingw (though I don't
> really understand what difference it would make, because something seems to
> be missing in the explanation (or more probably there's something I don't
> understand;-) and it seems to be a bit cumbersome as well if you're having a
> large product with a long lifetime)
That says you could build Cygwin apps using MS VC/VS, but must first build all
libraries you use, including cygwin, as MS VC/VS compatible DLLs using gcc,
impdef, and lib, and call their routines via Windows APIs, as they duplicate
msvcrt routines. Both cygdrop and cygrunsrv do something similar:
$ cygcheck cygdrop
Found: C:\...\cygwin64\bin\cygdrop.exe
C:\...\cygwin64\bin\cygdrop.exe
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
$ cygcheck cygrunsrv
Found: C:\...\cygwin64\bin\cygrunsrv.exe
C:\...\cygwin64\bin\cygrunsrv.exe
C:\...\cygwin64\bin\cygwin1.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\USER32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\GDI32.dll
Msys/2/Mingw allow Windows apps to be built by them or their Mingw Cygwin
packages, to run natively/standalone under Windows, so they can be used when
building, installing, or maintaining Cygwin, including e.g. cygcheck and setup:
$ cygcheck cygcheck
Found: C:\...\cygwin64\bin\cygcheck.exe
C:\...\cygwin64\bin\cygcheck.exe
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\PSAPI.DLL
C:\Windows\system32\USER32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\GDI32.dll
C:\Windows\system32\WININET.dll
$ cygcheck setup-x86_64
Found: C:\...\setup-x86_64.exe
C:\...\setup-x86_64.exe
C:\Windows\system32\ADVAPI32.dll
C:\Windows\system32\msvcrt.dll
C:\Windows\system32\ntdll.dll
C:\Windows\system32\KERNELBASE.dll
C:\Windows\system32\SECHOST.dll
C:\Windows\system32\RPCRT4.dll
C:\Windows\system32\KERNEL32.dll
C:\Windows\system32\COMCTL32.dll
C:\Windows\system32\GDI32.dll
C:\Windows\system32\win32u.dll
C:\Windows\system32\USER32.dll
C:\Windows\system32\ole32.dll
C:\Windows\system32\combase.dll
C:\Windows\system32\bcryptPrimitives.dll
C:\Windows\system32\PSAPI.DLL
C:\Windows\system32\SHELL32.dll
C:\Windows\system32\SHLWAPI.dll
C:\Windows\system32\WININET.dll
C:\Windows\system32\WS2_32.dll
> In my honest opinion I think this disability to use cygwin-libraries from
> windows-applications kind of limits some of cygwins purpose, but I do still
> think cygwin is a great open source project ;-)
You have a choice under Cygwin of:
- using Cygwin POSIX libraries with the Cygwin Unix emulation interface,
allowing you to build and run most packages that run under Unix, without system
(e.g. BSD, Darwin/MacOSX, or Linux) dependencies, including Cygwin/X to build
and run X Window packages, or else
- using Mingw packages and utilities with the Windows APIs.
--
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.]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-30 14:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-26 9:31 Using cygwin-dll with msvc-exe sten.kristian.ivarsson
2020-06-26 17:13 ` Andrey Repin
2020-06-30 7:19 ` Sv: " sten.kristian.ivarsson
2020-06-26 17:32 ` Brian Inglis
2020-06-30 7:15 ` Sv: " sten.kristian.ivarsson
2020-06-30 14:45 ` Brian Inglis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).