bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

runpath vs. rpath in ld


From: Simpson, Kenny
Subject: runpath vs. rpath in ld
Date: Mon, 14 Oct 2002 15:32:23 -0400

In elflink.h I see:
        /* When we see DT_RPATH before DT_RUNPATH, we have
           to clear runpath.  Do _NOT_ bfd_release, as that
           frees all more recently bfd_alloc'd blocks as
           well.  */
        if (rpath && hash_table->runpath)
            hash_table->runpath = NULL;

but this clears all the runpath info during a link as the hash table from
the info is shared.
In eelf_i386.c:
        rp = bfd_elf_get_runpath_list (output_bfd, &link_info);
        for (; !found && rp != NULL; rp = rp->next)
          {
            found = (rp->by == l->by
                && gldelf_i386_search_needed (rp->name,
                                   l->name,
                                   force));

The behavior I'm seeing is the following:
        I have an external library (libext1.so), which lives in ~/ext1.
        A shared library (libfoo.so) is created which links against
libext.so and records a DT_RUNPATH for ~/ext1.
        Another shared library (libbar.so) is created with a DT_RUNPATH for
some other directory (ext2/libext2.so).
        I attempt to create a binary (baz) that links against libfoo, and
libbar.
        The link fails as libext1 cannot be found.

        If I remove the line in elflink.h, this works, but I'm sure its not
the right fix.

Just to codify the above:

mkdir ext1;
mkdir ext2;

dummy.c:
        /* empty */

main.c:
        int main() { return 0; }

Makefile:
        ext1/libext1.so: dummy.c
                gcc -shared dummy.c -o $@

        ext2/libext2.so: dummy.c
                gcc -shared dummy.c -o $@

        libfoo.so: ext1/libext1.so
                gcc -shared -Lext1 -Wl,-rpath,ext1 -Wl,--enable-new-dtags
-lext1 -o $@

        libbar.so: ext2/libext2.so
                gcc -shared -Lext2 -Wl,-rpath,ext2 -Wl,--enable-new-dtags
-lext2 -o $@

        baz: main.c libbar.so libfoo.so
                gcc main.c -L. -Wl,-rpath,. -lfoo -lbar -o $@

make baz

With the runpath-clearing line commented out, this works.  With it, this
fails with:
        warning: libext1.so, needed by ./libfoo.so, not found (try using
-rpath, or -rpath-link)

Peppering printf's in eelf_i386.c shows that it only sees the runpath
entries from libbar.so.

This is with binutils-2.13.90.0.10 on a Linux 2.4.18/glibc 2.2.5/P4 using
gcc 2.95.2.

Thanks,
-Kenny




reply via email to

[Prev in Thread] Current Thread [Next in Thread]