* Visibility of compiler symbols between executables and DLLs @ 2005-09-26 9:32 Nick Glencross 2005-09-26 9:42 ` Max Bowsher 0 siblings, 1 reply; 6+ messages in thread From: Nick Glencross @ 2005-09-26 9:32 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Visibility of compiler symbols between executables and DLLs 2005-09-26 9:32 Visibility of compiler symbols between executables and DLLs Nick Glencross @ 2005-09-26 9:42 ` Max Bowsher 2005-09-26 10:22 ` Brian Dessent 2005-09-26 21:41 ` Nick Glencross 0 siblings, 2 replies; 6+ messages in thread From: Max Bowsher @ 2005-09-26 9:42 UTC (permalink / raw) To: Nick Glencross, cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Visibility of compiler symbols between executables and DLLs 2005-09-26 9:42 ` Max Bowsher @ 2005-09-26 10:22 ` Brian Dessent 2005-09-26 13:40 ` Christopher Faylor 2005-09-27 0:43 ` Charles Wilson 2005-09-26 21:41 ` Nick Glencross 1 sibling, 2 replies; 6+ messages in thread From: Brian Dessent @ 2005-09-26 10:22 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Visibility of compiler symbols between executables and DLLs 2005-09-26 10:22 ` Brian Dessent @ 2005-09-26 13:40 ` Christopher Faylor 2005-09-27 0:43 ` Charles Wilson 1 sibling, 0 replies; 6+ messages in thread From: Christopher Faylor @ 2005-09-26 13:40 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Visibility of compiler symbols between executables and DLLs 2005-09-26 10:22 ` Brian Dessent 2005-09-26 13:40 ` Christopher Faylor @ 2005-09-27 0:43 ` Charles Wilson 1 sibling, 0 replies; 6+ messages in thread From: Charles Wilson @ 2005-09-27 0:43 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Visibility of compiler symbols between executables and DLLs 2005-09-26 9:42 ` Max Bowsher 2005-09-26 10:22 ` Brian Dessent @ 2005-09-26 21:41 ` Nick Glencross 1 sibling, 0 replies; 6+ messages in thread From: Nick Glencross @ 2005-09-26 21:41 UTC (permalink / raw) To: Max Bowsher, cygwin 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/ ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-09-27 0:25 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-09-26 9:32 Visibility of compiler symbols between executables and DLLs Nick Glencross 2005-09-26 9:42 ` Max Bowsher 2005-09-26 10:22 ` Brian Dessent 2005-09-26 13:40 ` Christopher Faylor 2005-09-27 0:43 ` Charles Wilson 2005-09-26 21:41 ` Nick Glencross
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).