Topic
3 replies Latest Post - ‏2012-06-27T20:06:31Z by bdellegrazie
bdellegrazie
bdellegrazie
5 Posts
ACCEPTED ANSWER

Pinned topic Dependent shared library in debug mode gives duplicate debugger symbols

‏2012-06-25T16:18:11Z |
Hi,

I'm using AIX 6.1 and XLC 10.1.0.1.

I'm trying to compile two shared libraries (.so with runtime linking) and a main applicaiton in debug mode and I am getting duplicate symbols (__dbargs, __dbsubc, __dbsubg, __dbsubn) from the debugger library (libg.a).

A test case is attached with a simple Makefile.
The two shared libraries and main are trivial (source code, makefile attached in .zip)

Library sum (libsum.so) has only one function which adds two integers:
include "sum.h"
int sum( int x, int y )
{
return x+y;
}
The header file (sum.h) just contains the usual include guards and the function signature
The export file looks like this:
#!..
sum

Library take2 (libtake2.so) has only one function which uses sum and then subtracts two:
#include "sum.h"
#include "take2.h"
int sum_minus_2(int x, int y)
{
return sum(x,y)-2;
}
The header file (take2.h) just contains the usual include guards and the function signature
The export file looks like this:
#!..
sum_minus_2

The main program is trivial also:
#include "take2.h"
#include <stdio.h>

int main( int argc, const char* argv[] )
{
printf( "1+8-2=7, 1+8-2=%d\r\n", sum_minus_2(1, 8) );
}

Both libraries are linked using the following makefile:
  1. Dumb makefile to build the test application
  2. This could absolutely be optimised more but that would cloud the issue
CFLAGS=-g
LDFLAGS=-g -bnoipath
LDFLAGS_SO=-G
CC=xlc

all: test

sum.c.o: sum.c sum.h
$(CC) $(CFLAGS) -o sum.c.o -c sum.c

libsum.so: sum.c.o sum.exp
$(CC) $(LDFLAGS) $(LDFLAGS_SO) -bE:sum.exp -o libsum.so sum.c.o

take2.c.o: take2.c take2.h
$(CC) $(CFLAGS) -o take2.c.o -c take2.c

libtake2.so: take2.c.o take2.exp sum.exp
$(CC) $(LDFLAGS) $(LDFLAGS_SO) -bE:take2.exp -bI:sum.exp -o libtake2.so take2.c.o

test.c.o: test.c libsum.so libtake2.so
$(CC) $(CFLAGS) -o test.c.o -c test.c

test: test.c.o libsum.so libtake2.so
$(CC) $(LDFLAGS) -brtl -o test test.c.o libsum.so libtake2.so -L.

clean:
rm -f *.o
rm -f *.so
rm -f test

However the result when linking 'test' is:
ld: 0711-224 WARNING: Duplicate symbol: __dbargs
ld: 0711-224 WARNING: Duplicate symbol: __dbsubc
ld: 0711-224 WARNING: Duplicate symbol: __dbsubg
ld: 0711-224 WARNING: Duplicate symbol: __dbsubn
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
dump -Tv confirms that these symbols are being exported in every library from libg.a which is listed as a debugger library.

The problem only occurs when linking with debug turned on (i.e. when using '-g' during link step)

Any ideas what I'm doing wrong?
Is it possible to use RTL and specify debug mode?
Is it correct to specify -g to the compiler when performing the link step?

Any help appreciated,

Thanks,

Brett
Updated on 2012-06-27T20:06:31Z at 2012-06-27T20:06:31Z by bdellegrazie
  • flodstrom
    flodstrom
    57 Posts
    ACCEPTED ANSWER

    Re: Dependent shared library in debug mode gives duplicate debugger symbols

    ‏2012-06-26T16:55:11Z  in response to bdellegrazie
    As you have noticed it appears to work, but still have not done what you intended to do.

    You should be careful to not overuse the -g option. I know that the -g seem to be the default option to use these days (for some odd reason...), even if no debugging are done at all? Use -g only if you really need to debug something.

    Still when overusing the -g option there's indeed one peculiar thing with AIX and I'm not sure weather it's a bug or if it's intended to work like it does?

    If you have two or more shared objects linked using the -g option you will trigger the behaviour you see. If there were only one so linked using -g then there would be no conflicts.

    I think this problem happens when the compiler is used as frontend when linking shared objects. If ld was used directly it would obviously not know what the -g option is and you would get an error. Further on you can also see that the so (when linked using -g) somehow have a dependency on the kernel, libc and libcrypt?! A simple so like either of these examples should not have any dependencies?

    With this in mind I would advice some careful use of the -g option, especially when linking a shared object.

    If you do want have the extra debugging in a so then I would enable that separately for each object I want to debug. Like this for example if I want to debug sum.c.

    
    xlc -g -c sum.c xlc -G -o libsum.so sum.o ... xlc -brtl -o test test.c -L. -lsum -ltake2
    


    Please feel free to comment. I may also have missed something here?
    • bdellegrazie
      bdellegrazie
      5 Posts
      ACCEPTED ANSWER

      Re: Dependent shared library in debug mode gives duplicate debugger symbols

      ‏2012-06-26T17:48:37Z  in response to flodstrom
      Hi Flodstrom,

      Thanks again for responding.

      The bit I haven't mentioned is that I'm usually using cmake and when its building in 'Debug' mode it automatically supplies the -g option to all target build and link commands.

      Using -v on the link lines I can see the libg.a library is being statically linked and exported by the compiler whenever -g is used.

      To ask a potentially stupid question however...
      If the -g option is omitted from the link step of everything except the final executable target,
      is debugging information still included in the shared libraries?
      FYI, the build succeeds but I've no idea if debugging into the library would work (haven't got that far testing).

      Thanks,

      Brett
      • bdellegrazie
        bdellegrazie
        5 Posts
        ACCEPTED ANSWER

        Re: Dependent shared library in debug mode gives duplicate debugger symbols

        ‏2012-06-27T20:06:31Z  in response to bdellegrazie
        To answer my own question, I tried compiling the object files with "-g" but when linking I omitted "-g" for all shared libraries. I only used "-g" on linking the main executable. I then tried to step through the program and this succeeded, including into the shared libraries.

        So it looks like the correct solution is:
        (1) Compile everything with "-g"
        (2) Link only the final executable with "-g"

        Hopefully this will help someone else later.

        Brett