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)

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.

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.

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

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"