Using cygwin-dll with msvc-exe

public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed

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