Visibility of compiler symbols between executables and DLLs

Visibility of compiler symbols between executables and DLLs

[Nick Glencross]

Guys,

I've done some research on this and don't believe that it's a
perennial question that keeps coming up!

On many platforms compilation symbols in an executable are not made
visible to its Shared Library/DLLs by default, but this can often be
overridden with a compiler flag to change the policy. My question in a
nutshell then is whether cygwin has the ability to have a DLL access a
global variable within the executable that loads it? As an obvious
follow on, if yes, then how do you go about doing it?

Everything that I've seen indicates that this isn't possible, due to
limitations imposed by DLLs, but would appreciate believing this with
a bit more confidence,

Thanks in advance,

Nick

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Visibility of compiler symbols between executables and DLLs

[Max Bowsher]

Nick Glencross wrote:
> Guys,
>
> I've done some research on this and don't believe that it's a
> perennial question that keeps coming up!
>
> On many platforms compilation symbols in an executable are not made
> visible to its Shared Library/DLLs by default, but this can often be
> overridden with a compiler flag to change the policy. My question in a
> nutshell then is whether cygwin has the ability to have a DLL access a
> global variable within the executable that loads it? As an obvious
> follow on, if yes, then how do you go about doing it?
>
> Everything that I've seen indicates that this isn't possible, due to
> limitations imposed by DLLs, but would appreciate believing this with
> a bit more confidence,

I'm fairly sure that it is impossible. Actually, it might be possible if 
there was a flag to convice GCC to add an import table to the built .exe, 
but last time I investigated that, there was no such flag. But even if that 
was possible, the .dll would need to explicitly link against the .exe that 
was to load it, for this method to work.

The standard workaround is to put whatever symbols both the .exe and the 
.dll both need access to into a second .dll, which both of the original 
components then link against.

Interestingly, the difficulties created by DLLs are at least slightly 
similar to those created by OS X two-level-namespace linking.


Max.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Visibility of compiler symbols between executables and DLLs

[Brian Dessent]

Max Bowsher wrote:

> I'm fairly sure that it is impossible. Actually, it might be possible if
> there was a flag to convice GCC to add an import table to the built .exe,
> but last time I investigated that, there was no such flag. But even if that
> was possible, the .dll would need to explicitly link against the .exe that
> was to load it, for this method to work.

This does actually work, AFAIK.  You need to use __declspec(dllexport)
on the symbols in the .exe, and produce an import library
(-Wl,--out-implib) when building the .exe which is then used in linking
the .dll.  It hardcodes the name of the .exe in the .dll though, so it
also means that you cannot use the .dll as a general purpose library.

Refactoring out to a common .dll is much cleaner.  You can also design
the API so that you pass pointers to the symbols as arguments to
functions in the .dll.

The archives of this list (and the mingw list FWIW) have numerous
versions of this question, because it comes up all the time from people
that are used to the way linux shared libraries work.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Visibility of compiler symbols between executables and DLLs

[Christopher Faylor]

On Mon, Sep 26, 2005 at 02:32:25AM -0700, Brian Dessent wrote:
>Max Bowsher wrote:
>
>> I'm fairly sure that it is impossible. Actually, it might be possible if
>> there was a flag to convice GCC to add an import table to the built .exe,
>> but last time I investigated that, there was no such flag. But even if that
>> was possible, the .dll would need to explicitly link against the .exe that
>> was to load it, for this method to work.
>
>This does actually work, AFAIK.  You need to use __declspec(dllexport)
>on the symbols in the .exe, and produce an import library
>(-Wl,--out-implib) when building the .exe which is then used in linking
>the .dll.  It hardcodes the name of the .exe in the .dll though, so it
>also means that you cannot use the .dll as a general purpose library.

Right on both counts.  This isn't impossible.  It's just not really convenient/useful.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Visibility of compiler symbols between executables and DLLs

[Nick Glencross]

Max,

Thanks, that's the conclusion that I had come to. On other UNIX-based
platforms it's possible without actually linking with the .exe,
provided you have compiled with the right flags (-shared on Linux, or
-E on HP-UX). With this done the .exe exposes its global symbols to
subsequently loaded libraries which can then import them. Looks like
DLLs are are more restrictive, but I couldn't find anything documented
about it for cygwin.

Thanks,

Nick

On 9/26/05, Max Bowsher <maxb@ukf.net> wrote:
> Nick Glencross wrote:
> > Guys,
> >
> > I've done some research on this and don't believe that it's a
> > perennial question that keeps coming up!
> >
> > On many platforms compilation symbols in an executable are not made
> > visible to its Shared Library/DLLs by default, but this can often be
> > overridden with a compiler flag to change the policy. My question in a
> > nutshell then is whether cygwin has the ability to have a DLL access a
> > global variable within the executable that loads it? As an obvious
> > follow on, if yes, then how do you go about doing it?
> >
> > Everything that I've seen indicates that this isn't possible, due to
> > limitations imposed by DLLs, but would appreciate believing this with
> > a bit more confidence,
>
> I'm fairly sure that it is impossible. Actually, it might be possible if
> there was a flag to convice GCC to add an import table to the built .exe,
> but last time I investigated that, there was no such flag. But even if that
> was possible, the .dll would need to explicitly link against the .exe that
> was to load it, for this method to work.
>
> The standard workaround is to put whatever symbols both the .exe and the
> .dll both need access to into a second .dll, which both of the original
> components then link against.
>
> Interestingly, the difficulties created by DLLs are at least slightly
> similar to those created by OS X two-level-namespace linking.
>
>
> Max.
>
>

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Visibility of compiler symbols between executables and DLLs

[Charles Wilson]

Brian Dessent wrote:
> Max Bowsher wrote:
> 
> 
>>I'm fairly sure that it is impossible. Actually, it might be possible if
>>there was a flag to convice GCC to add an import table to the built .exe,
>>but last time I investigated that, there was no such flag. But even if that
>>was possible, the .dll would need to explicitly link against the .exe that
>>was to load it, for this method to work.
> 
> 
> This does actually work, AFAIK.  You need to use __declspec(dllexport)
> on the symbols in the .exe, and produce an import library
> (-Wl,--out-implib) when building the .exe which is then used in linking
> the .dll.  It hardcodes the name of the .exe in the .dll though, so it
> also means that you cannot use the .dll as a general purpose library.

Correct.

You can also link the executable using a .def file listing the exports 
you want -- this way you don't need to use __declspec() in your app or 
library code (auto-import will work as well).  However, even in this 
case you also need to generate an import library, as Brian describes above:

gcc -o foo.exe foo.def foo.o -lsomelib -Wl,--out-implib=foo.dll.a

And, as Max pointed out, when you link the DLL you have to give it a 
reference to the .exe's implib:

gcc -shared -o bar.dll -Wl,--out-implib=bar.dll.a bar.o foo.dll.a 
-lotherlibs

Which brings up TWO problems:

(1) foo.exe can't depend on bar.dll (because then each would need the 
other's implib in order to link; chicken/egg problem)

(2) As Brian points out, the 'foo.exe' name will be hardcoded into 
bar.dll's internal import list, so bar can't be used with any other 
executable.

> Refactoring out to a common .dll is much cleaner.  You can also design
> the API so that you pass pointers to the symbols as arguments to
> functions in the .dll.

Yep.

--
Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/