Hi > Harold L Hunt II wrote: > > > I tried a build without $(SMLIB) and $(ICELIB) in SharedXtReqs, but it > > fails to link due to unresolved symbols (all symbols must be resolved at > > library link time in DLLs on Windows). > > > > I will have to consult with the rest of the Cygwin people to see what we > > should do now. > > I'm working on a similar problem with libXfont. The more I think about it, > the more problems I see and I think this is a feature, which ld > must provide. > > The cases where the symbol is undefined in the shared library might get > resolved with dispatch functions and code in the program which changes > the pointer which is used by the dispatch code. > This might be possible, but how could ld find the propper library ?
Let me explain a few notes to this topic, may be this helps to understand the relating things a little bit more. linux and other unix os uses a runtime search for such symbols through ld.so, ldconfig and friends. (see http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 and http://www.cs.princeton.edu/cgi-bin/man2html?ld.so.1:1 for more informations) Beside the recommended linker patch, something like the above mentioned ld.so functionality has to be implemented too. There must be a runtime specific code located somewhere in the (mingw- and cygwin's) applications startup library (like the pseudo-runtime-reloc code see http://www.cygwin.com/ml/cygwin-patches/2002-q4/msg00205.html) or somewhere else. As far as I can see the runtime stuff could be implemented in two manners: 1. when the dll is loaded by the dll startup code. The loading stuff searches the PATH (or using an newly introduced LD_LIBRARY_PATH) environment var for dll's and their exported symbols to find a valid symbol and resolves this reference. 2. at the time an unresolved symbol is called (lazy binding, ms and other native win32 linkers are supporting such a mode). Unfortunally this work only with functions symbols and not with data symbols, because of the different accessing mode (call versus content loading/writing). Both cases increases the loading time of an application and may end up in seg faults in case more than one dll exports the requested symbol and the search path is searched in an unwanted order. The increased loading time could be reduced by a dependency cache like ldconfig does, but this decision could be reached in real test scenarios. For the dll ordering problem currently I have no idea how to fix, may be someone else can help with this. The linker patch should contain the following parts: 1. a command line options to enable/disable dynamic-runtime-linking support ( --[no-]allow-shlib-undefined seems to be usable) 2. it has to detect unresolved symbols and shuld build internal code stubs (like the regular function import stub) to solve symbol requests. For the runtime stuff is has to provide internal tables (the dynamic import table) allowing the runtime stuff to find and resolve this dependencies. These import tables are probably not be visible in the PE-dll supplied import, they are only internal defined. Another approach seems to be to link all such undefined symbols to one known symbol in an specific helper dll, augmented with the original symbol in an currently unspecified decoration, so that this dll is able to solve the undefined symbol. The advantage of this solution is that there is no specific runtime stuff in each dll or application necessary. All this stuff is located in one dll and could be upgraded and improved independently from the real application or dll's (for cygwin this dll will be probably cygwin1.dll, for mingw the mingwxx.dll). BTW: I've cc'ed this email to the binutils list, because there are more people with ld knowledge, who can give some more informations/solutions for this issue. Hope that help Ralf (It may be possible to us a dummy dll'