https://sourceware.org/bugzilla/show_bug.cgi?id=18652
Bug ID: 18652
Summary: --no-allow-shlib-undefined stopped policing explicit
mention of all dependencies
Product: binutils
Version: 2.23
Status: NEW
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: martin.dorey at hds dot com
Target Milestone: ---
Before
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blobdiff;f=ld/emultempl/elf32.em;h=83a554fa7495e169e02f9157ac7bffc1609282b7;hp=ea7bad08e7ef189bfb2a66d9b7d65ebe69bce4f6;hb=4706eab946cabc77df441377e1e7ee7767197076;hpb=0b000dbb4929f9478633f3bf4a2a84c989befecb
ie:
+2013-04-26 Alan Modra <amo...@gmail.com>
+
+ * emultempl/elf32.em (gld${EMULATION_NAME}_after_open): Test
+ unresolved_syms_in_shared_libs rather than !executable to
+ determine whether to load DT_NEEDED libraries.
... we could check whether our shared libraries had accidentally acquired a new
dependency on eg strcpy like this:
martind@swiftboat:~/tmp/D110979$ cat use-strcpy.c
#include <string.h>
void* use = &strcpy;
martind@swiftboat:~/tmp/D110979$ gcc -shared use-strcpy.c -o use-strcpy.so
martind@swiftboat:~/tmp/D110979$ readelf --dynamic use-strcpy.so | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
martind@swiftboat:~/tmp/D110979$
Before that change, we'd see:
martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared
use-strcpy.so --no-allow-shlib-undefined
use-strcpy.so: undefined reference to `strcpy@GLIBC_2.2.5'
martind@swiftboat:~/tmp/D110979$
... unless we specified the library explicitly, along with everything it
depends on:
martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared
use-strcpy.so /lib/x86_64-linux-gnu/libc-2.13.so /lib64/ld-linux-x86-64.so.2
--no-allow-shlib-undefined
martind@swiftboat:~/tmp/D110979$
With that change, however, the link silently succeeds:
martind@swiftboat:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared
use-strcpy.so --no-allow-shlib-undefined
martind@swiftboat:~/tmp/D110979$
... providing that all the dependencies can be satisfied on the host. I wonder
if that was deliberate. I foresee a "yes" and a "closed invalid" but I thought
it worth noting, where Google will find it, that the semantics of the
--no-allow-shlib-undefined switch was changed.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
