It seems that if you change RPATH to be: "/full/path/to/dist/bin:/full/path/to/dist" for the development builds, then the shared libraries will be found.
It is not necessary to have the developer build be relocatable, right? So it is not necessary to use $ORIGIN or "."? --chris brian.lu wrote: > Hi, experts, > > Thanks very much for your valuable help. > > Now I have another question: > On solaris, it is recommended to use RUNPATH instead of LD_LIBRARY_PATH > to locate shared libraries. > > For Mozilla, we use following way to locate shared libraries: > set "$ORIGIN: $ORIGIN/.." into every shared libraries' runpath (by using > -R '$ORIGIN:$ORIGIN/..' option). This works fine in the release build. > But in developer's workspace, Mozilla shared libraries are put under > directories "$MOZILLA_ROOT/dist/bin" and > "$MOZILLA_ROOT/dist/bin/components". > But these shared libraries are actually *symbol links* which link to > real shared libraries scattered in other sub-directories under > $MOZILLA_ROOT. > Shared libraries under "dist/bin/components" depend on some shared > libraries under "dist/bin". > > In this situation, $ORIGIN will have problem to locate shared libraries, > because $ORIGIN will be replaced with *real path* > (i.e. the symbol link points to). E.g. a shared library > dist/bin/components/libbar.so depends on dist/bin/libfoo.so. When > dist/bin/components/libbar.so is loaded > is will use libbar.so's *real-path/.. *instead of > *dist/bin/components/..* to try to locate libfoo.so. Of course, > ld.so.1 will fail to find it. > > To solve the problem, I want to use "*.*" to replace "$ORIGIN" in "-R" > option. Can I do that? > I think the only difference between "$ORIGIN" and "." is the way they > handle symbol link. Is that right? > > Thanks again > > Brian > > Michael Walker wrote: > >> Adam Leventhal wrote: >> >>> On Mon, Nov 07, 2005 at 06:22:13AM -0800, Michael Walker wrote: >>> >>>>> In your last e-mail, you say " When *libthread* is loaded,you cause >>>>> the threading libraries to enforce the POSIX model for the threads >>>>> library instead of the Solaris one." I think it should be >>>>> "libpthread" right? >>>> >>>> >>>> >>>> yes - libpthread. >>> >>> >>> >>> >>> As far as I know, as of Solaris 10 linking against libpthread is a no-op >>> in terms of functionality. If you look closely, you'll see that >>> libpthread >>> is pretty much empty -- there's not even a .text section. >>> >>> Adam >>> >> >> >> Yup - Adam's right. libpthread caused a behaviour change back >> in S9. Things were changes in S10 so that it's no longer >> required. >> >> >> _Mike_ >> >> > > _______________________________________________ > tools-linking mailing list > tools-linking at opensolaris.org
