AW: Problems with shared lesstif and shared Xt on Cygwin/XFree86

["Ralf Habacker" <Ralf dot Habacker at freenet dot de>]

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'