At 10:21 Uhr +0100 25.01.2002, Martin Costabel wrote: >Max, > >This information is also in the lesstif FAQ at /sw/LessTif/FAQ and >/sw/LessTif/doc/FAQ.html. I remember mentioning this two days ago in the >"XFree86 version and grace" thread on fink-users. The FAQ even mentions >it in the same way we are seeing it, with "DropSiteManager".
Sorry, must have missed it in the thread. But as I said, I knew it was not new :) >The problem seems to be runtime linking, because you can take the same >binary (xmgrace in this case, but it is the same for nedit) and run it >in the presence of libXt from XFree86-4.1.0: It works; run it with libXt >from XFree86-4.2.0: Error. It doesn't matter with which version you link >it at compile time. > >OTOH, Apple's linker does not respect the command line link order >either, as can be seen from the following output from the nedit build: > >cc -O2 -no-cpp-precomp -I/usr/X11R6/include -I/sw/include nc.o >../util/libNUtil.a -L/sw/lib -lXm -L/usr/X11R6/lib -lXpm -lXext -lXt >-lSM -lICE -lX11 -o nc >/usr/bin/ld: warning suggest use of -bind_at_load, as lazy binding may >result in errors or different symbols being used >symbol _vendorShellClassRec used from dynamic library >/usr/X11R6/lib/libXt.dylib(Vendor.o) not from earlier dynamic >library /sw/LessTif/Motif2.0/lib/libXm.2.dylib(Vendor.lo) >symbol _vendorShellWidgetClass used from dynamic library >/usr/X11R6/lib/libXt.dylib(Vendor.o) not from earlier dynamic >library /sw/LessTif/Motif2.0/lib/libXm.2.dylib(Vendor.lo) Hm, that's weird. I have in various projects relayed on the link order that's the first time I see this problem... ah wait, the difference is, here we use only shared libs. Ah-ha! They get linked at run time. A brief look at the ld man page under "DYNAMIC SHARED LIBRARIES" reveals a lot of useful information. To quote it: >However, the static link editor always >produces the same linking as the dynamic linker as long as >none of the dynamic shared libraries define the same sym- >bol. Different linking can occur only when there is more >than one definition of a symbol and the library modules >that contain the definitions for that symbol do not define >and reference exactly the same symbols. In this case, >even different executions of the same program can produce >different linking because the dynamic linker binds unde- >fined functions as they are called, and this affects the >order in which undefined symbols are bound So, maybe the suggestion the linker gives us, to use "-bind_at_load" might indeed be the way to go. Maybe somebody could test the result with this? Max -- ----------------------------------------------- Max Horn Software Developer email: <mailto:[EMAIL PROTECTED]> phone: (+49) 6151-494890 _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
