[Top][All Lists]

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

[Bug ld/18652] New: --no-allow-shlib-undefined stopped policing explicit

From: martin.dorey at hds dot com
Subject: [Bug ld/18652] New: --no-allow-shlib-undefined stopped policing explicit mention of all dependencies
Date: Fri, 10 Jul 2015 01:03:02 +0000


            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: ---


+2013-04-26  Alan Modra  <address@hidden>
+       * 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:

address@hidden:~/tmp/D110979$ cat use-strcpy.c 
#include <string.h>

void* use = &strcpy;
address@hidden:~/tmp/D110979$ gcc -shared use-strcpy.c -o use-strcpy.so
address@hidden:~/tmp/D110979$ readelf --dynamic use-strcpy.so | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

Before that change, we'd see:

address@hidden:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared
use-strcpy.so --no-allow-shlib-undefined
use-strcpy.so: undefined reference to address@hidden'

... unless we specified the library explicitly, along with everything it
depends on:

address@hidden:~/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

With that change, however, the link silently succeeds:

address@hidden:~/tmp/D110979$ ~/download/binutils-gdb/ld/ld-new -shared
use-strcpy.so --no-allow-shlib-undefined

... 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.

reply via email to

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