This is the mail archive of the
mailing list for the Cygwin project.
Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
- From: Gary Schneir <gary at fhoosh dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 15 Sep 2017 06:51:32 -0700
- Subject: Re: Problem with differences with DLOPEN / DLSYM compared to ubuntu (16.04) / debian (stretch).
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org>
Thanks for the response but I am a little confused by it. If Cygwin is
supposed to provide POSIX API functionality and DLOPEN / DLSYM are
supported in CYGWIN, then I shouldn't care about the underlying
complexity or restrictions of running within the Windows environment and
using DLLs. The behavior should be the same as in other POSIX environments.
If you are saying that I did not include some sort of
__declspec(dllexport) directive in my code so that it can find my
symbols, that is something else but you indicate that you think cygwin
hides that complexity in shared libraries.
On 09/14/2017 06:15 PM, Kaz Kylheku wrote:
> 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
> 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
> for the external symbols.
> It's probably not configured to do that for the symbols in a regular
> 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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple