Bug 111780

Summary: Can't resolve symbols in shared lib with objects from static lib
Product: Red Hat Enterprise Linux 2.1 Reporter: Kurtis D. Rader <krader>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 2.1CC: fweimer
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-12-10 08:34:54 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Kurtis D. Rader 2003-12-10 01:13:56 UTC
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:
Always

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 08:34:54 UTC
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).