Bug 111780 - Can't resolve symbols in shared lib with objects from static lib
Can't resolve symbols in shared lib with objects from static lib
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-12-09 20:13 EST by Kurtis D. Rader
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-10 03:34:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Kurtis D. Rader 2003-12-09 20:13:56 EST
From Bugzilla Helper:
User-Agent: Opera/7.11 (Linux 2.4.20-20.8 i686; U)  [en]

Description of problem:
Filing this on behalf of a joint customer who initially reported this
failure when building an app:

    /usr/bin/ld: /lib/ld-linux.so.2: indirect symbol
    `__libc_internal_tsd_set' to `__libc_internal_tsd_set@@GLIBC_2.0' 
        is a loop
    /lib/ld-linux.so.2: could not read symbols: Invalid operation

This can be reproduced with a link command like this one:

    /usr/bin/gcc -o mixed_link_test main.o \
        -L. -Wl,-Bdynamic -lcsrclib1 -Wl,-Bstatic -lcsrclib2

I found that upgrading glibc to at least 2.2.4-32.3 resolves that 
problem. However, it produces an executable object which dies from a 
SIGSEGV early in the process bootstrap sequence (specifically, 
somewhere in the dynamic loader bootstrap code). This failure mode 
occurs even with the latest glibc errata for RHAS 2.1. It does not 
occur on Red Hat 8.0.

Customer has a need to resolve symbols in a shared library with 
objects in a static library. For the moment I've given them the 
following, ugly, workaround:

  /usr/bin/gcc -g -o mixed_link_test main.o -L. \
  -Wl,--whole-archive -Wl,-Bstatic -lcsrclib2 -Wl,-no-whole-archive \
  -Wl,-Bdynamic -lcsrclib1

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a makefile with the following contents:

    mixed_link_test: main.o csrclib1.so csrclib2.a
        /usr/bin/gcc -g -o mixed_link_test main.o -L. \
                -Wl,-Bdynamic -lcsrclib1 -Wl,-Bstatic -lcsrclib2 

    main.o: main.c csrclib1.h csrclib2.h
        /usr/bin/gcc -g -c main.c

    csrclib1.so: csrclib1.o
        /usr/bin/gcc -g -o libcsrclib1.so  -Wl,-shared  csrclib1.o 

    csrclib1.o: csrclib1.c csrclib1.h csrclib2.h
        /usr/bin/gcc -g -c -fpic csrclib1.c

    csrclib2.a: csrclib2.o
        /usr/bin/ar -r libcsrclib2.a csrclib2.o

    csrclib2.o: csrclib2.c csrclib2.h
        /usr/bin/gcc -g -c -fpic csrclib2.c

2. Create a file named main.c with the following contents:
extern void csrclib1_fn();
int main (int argc, char * argv[])
        csrclib1_fn ();
        return 0;

3. Create a file named csrclib1.c with the following contents:

#include <stdio.h>

extern void csrclib2_fn();
void csrclib1_fn ()
        printf ("csrclib1_fn called.\n");
        csrclib2_fn ();

4. Create a file named csrclib2.c with the following contents:

#include <stdio.h>

void csrclib2_fn ()
        printf ("csrclib2_fn called.\n");

5) make; LD_LIBRARY_PATH=`pwd` ./mixed_link_test

Actual Results:  Process dies due to a SIGSEGV.

Expected Results:  The following two lines appear on stdout:

csrclib1_fn called.
csrclib2_fn called.

Additional info:
Comment 1 Jakub Jelinek 2003-12-10 03:34:54 EST
Linking with -L. -Wl,-Bdynamic -lcsrclib1 -Wl,-Bstatic -lcsrclib2
is a bug, you never should link the system libraries statically
unless the whole link is -static.
It should be
-L. -Wl,-Bdynamic -lcsrclib1 -Wl,-Bstatic -lcsrclib2 -Wl,-Bdynamic
(though the first -Wl,-Bdynamic is unnecessary).

Note You need to log in before you can comment on or make changes to this bug.