* 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
* 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-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
* 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).