This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
- From: Kaz Kylheku <920-082-4242 at kylheku dot com>
- To: cygwin at cygwin dot com
- Date: Thu, 14 Sep 2017 18:15:51 -0700
- Subject: Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
- Authentication-results: sourceware.org; auth=none
On 14.09.2017 08:44, Gary Schneir wrote:
Can anyone provide some assistance to understanding the differences and
a way get a single code base to work in all three environments without
naming the library file?
On Cygwin, libraries are Windows DLL's. That appears to be a
conscious project decision.
The TL;DR is that Windows DLL's are not going to give you the behaviors
of ELF
shared libraries on GNU/Linux. Cygwin would probably have to whip up its
own
shared library format for that, or port one.
The complication doesn't seem worth it.
You can think of dlopen as a wrapper around LoadLibrary, and dlsym doing
GetProcAddress.
In Windows programming, doing GetProcAddress on symbols within an .exe
is something
that isn't normally done; it's not clear that it is supposed to work at
all.
For it to even have any hope of working, the function would have to be
somehow
declared "dllexport" (in Visual C terms).
I think the shared lib building mechanism under Cygwin hides that; there
is no
Visual C __declspec(dllexport) stuff:
See: https://cygwin.com/cygwin-ug-net/dll.html
Still, the toolchain has to be arranging for the equivalent of
__declspec(dllexport)
for the external symbols.
It's probably not configured to do that for the symbols in a regular
executable.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple