Re: tlug: Acrobat reader and libXt

["Andrew S. Howell" <andy@example.com>]

>>>>> "Stephen" == Stephen J Turnbull <turnbull@example.com> writes:

>>>>> "ash" == Andrew S Howell <andy@example.com> writes:
    ash> The strange thing is that ldd says that it can find
    ash> libXt.so.6 just fine.

>>>>> "Stephen" == Stephen J Turnbull <turnbull@example.com> writes:

    Stephen> `ldd' _finds_ _dependencies_, it does not _load_
    Stephen> _libraries_.

    ash> Well, isn't end result the same? I understood that ldd worked
    ash> by watching what libraries the program loads. I could be
    ash> completely wrong on this though...

    Stephen> No.  I'm not sure exactly what happens, but it's
    Stephen> definitely not that.  As I understand it, ldd munges the
    Stephen> environment of ld.so so that ld.so sees an argc of 0,
    Stephen> which recent (ie, in the lifetime of Scott Stone :-)
    Stephen> ld.so special-case to report on libs used.

Hmmm, you got me curious. It turns out that ldd is just a shell script
that, in the end does:

       LD_TRACE_LOADED_OBJECTS=1 exec ${RTLD} ${RELOCS} "$file" ||
exit 1

So it would seem that LD_TRACE_LOADED_OBJECTS is a flag to ld.so.

>From ChangeLog.6 for glibc-2.0.6 ( old, but had handy... )

Fri Jul 26 22:49:58 1996  Ulrich Drepper  <drepper@example.com>

        * elf/rtld.c (dl_main): Implement LD_TRACE_LOADED_OBJECTS
        environment variable handling.  This makes the dynamic linker
        only print loaded libraries and quit.

        * elf/ldd.sh.in: Don't use `rtld --list' but instead
        LD_TRACE_LOADED_OBJECTS environment variable to print needed
        objects.

I didn't happen to have the source for ld.so laying around, and its
too late to hunt down a CD, but I would from the description above, it
sounds like ld.so goes through the motions of exec'ing an app and
printing out what libs it would load.

    Stephen> I don't know just how far ld.so goes in creating this
    Stephen> report; maybe it loads the libraries, maybe it just reads
    Stephen> enough of them to learn their dependencies.  But the
    Stephen> conflicts that hose a library and result in "can't load"
    Stephen> messages do not necessarily occur under ldd, so the
    Stephen> process must be different.

I agree, it must be different. One thing I'm sure that would not be
resolved are libs that the app dynamically load itself. For example,
perl modules...

Regards,

	Andy
	
-------------------------------------------------------------------
Next Technical Meeting: February 13 (Sat), 12:30 place: Temple Univ.
** presentation: XEmacs, by Steven Baur and Martin Buchholz
Next Nomikai: March 19 (Fri), 19:30   Tengu TokyoEkiMae 03-3275-3691
-------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT