Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder2.hal-mli.net!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.system Subject: Re: rpath for library loading Date: Mon, 17 Dec 2012 15:03:34 +0000 Lines: 30 Message-ID: <87hank201l.fsf@sapphire.mobileactivedefense.com> References: <8738z5t0wl.fsf@araminta.anjou.terraraq.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 4sHLvB/Ij3UeTwbBpLGa/wvkzCykXAdt8ac0b0EvngHU1XW/IpQJewNDdK0ybxe24= Cancel-Lock: sha1:fl9OIz+SBHRQlK7FsOWw1GF7cnY= sha1:eqcPbON8JiTbX7az3qyzRf0Uxks= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: csiph.com comp.os.linux.development.system:485 Philipp Kraus writes: > On 2012-12-17 11:42:50 +0100, Richard Kettlewell said: [...] >> An rpath of . means it looks in the current directory at the time of >> execution, not in the same location as the object containing the rpath. > > That's bad. Can I add a flag that the rpath should be relative to the other > DLL? ,---- | RPATH TOKEN EXPANSION | The runtime linker provides a number of tokens that can be used | in an rpath specification (DT_RPATH or DT_RUNPATH). | | $ORIGIN | ld.so understands the string $ORIGIN (or equivalently | ${ORIGIN}) in an rpath specification to mean the | directory containing the application executable. Thus, | an application located in somedir/app could be compiled | with gcc -Wl,-rpath,'$ORIGIN/../lib' so that it finds an | associated shared library in somedir/lib no matter where | somedir is located in the directory hierarchy. `---- [ld.so(8)] BTW, a 'shared object' is something very much different than a 'dynamic link libray' which often isn't/ can't be shared dynamically because it doesn't use position-independent code.