This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Link extra-libs consistently with libc and ld.so
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>, <libc-ports at sourceware dot org>
- Date: Fri, 17 May 2013 14:41:58 -0700 (PDT)
- Subject: Re: Link extra-libs consistently with libc and ld.so
- References: <Pine dot LNX dot 4 dot 64 dot 1305090021040 dot 25137 at digraph dot polyomino dot org dot uk> <Pine dot LNX dot 4 dot 64 dot 1305140032090 dot 10338 at digraph dot polyomino dot org dot uk> <20130517202428 dot B17DA2C0BE at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1305172120310 dot 22690 at digraph dot polyomino dot org dot uk>
> > elfobjdir and elf-objpfx are redundant. We should consolidate on just one
> > or the other. I don't think it matters which. For linking, using ld.so
> > makes sense. There is no need to use $(rtld-installed-name).
>
> I've added this consolidation to the wiki todo list.
Good enough.
> Now, maybe sotruss-lib.so could be built in a different way that happens
> after linkobj/libc.so is built. But the principle of consistency with
> building with an installed compiler and libc suggests that linkobj/libc.so
> should only be used when necessary.
Fair enough.
> I'd think such a linker script might as well include absolute paths; a
We take some pains in other places to avoid those. It means you can move
your build directory around without breaking everything.
> No, tested with normal testsuite runs. I don't expect everything to be
> unchanged, given that various objects were previously linked
> unconditionally with ld.so and after the patch have a --as-needed link
> with ld.so (so some may not end up with a dependency on ld.so after all).
I'd like to see at least verification that no actual code changed, and
diffs of readelf -d output where it changed.
Thanks,
Roland