Multiple definitions of glibc symbols when linking several static libraries with gcc

Question

So I have made two libraries with gcc and ar: libwa.a and libws.a.

When I link them using -l flag in my project. I get this error:

/usr/bin/ld: .../lib/libws.a(bhns.c.o): in function `atoi': bhns.c:(.text+0x0): multiple definition of `atoi'; .../lib/libwa.a(axx.c.o):axx.c:(.text+0x0): first defined here /usr/bin/ld: .../lib/libws.a(bhns.c.o): in function `atol': bhns.c:(.text+0x20): multiple definition of `atol'; .../lib/libwa.a(axx.c.o):axx.c:(.text+0x20): first defined here /usr/bin/ld: .../lib/libws.a(bhns.c.o): in function `atoll': bhns.c:(.text+0x30): multiple definition of `atoll'; .../lib/libwa.a(axx.c.o):axx.c:(.text+0x30): first defined here /usr/bin/ld: .../lib/libws.a(bhns.c.o): in function `bsearch': bhns.c:(.text+0x40): multiple definition of `bsearch'; .../lib/libwa.a(axx.c.o):axx.c:(.text+0x40): first defined here /usr/bin/ld: .../lib/libws.a(bhns.c.o): in function `atof': bhns.c:(.text+0xc0): multiple definition of `atof'; .../lib/libwa.a(axx.c.o):axx.c:(.text+0xc0): first defined here

It seems that when I include <stdlib.h> header, it also defines atoi and those other functions as extern __inline, which provides one definition of those symbols per each library. For that reason there's are multiple definitions linker error.

Is there any way of going around this? I don't think this is expected behavior.

Can you provide a minimal reproducible example of both libs and the using code and how you link? — Yunnosch
– Yunnosch, Commented Oct 10, 2024 at 12:16
Merely including stdlib.h does not provide an external definition for any function, except possibly if your code has undefined behavior. For example, if it messes with reserved identifiers, such as __inline, then that might cause you all manner of grief. — John Bollinger
– John Bollinger, Commented Oct 10, 2024 at 13:33
@JohnBollinger, I figured it out, you put me on the right track. See my own answer for more info! Thanks — Wispy
– Wispy, Commented Oct 10, 2024 at 14:18

Wispy · Accepted Answer · 2024-10-10 14:39:52Z

As John pointed out. I had a piece of code in one of my header files that went like this:

# ifndef __attribute__ # define __attribute__(x) # endif

Because of it any __attribute__() macro expanded to nothing in header files.

I am still not sure why lack of attributes would cause this linker error but that error only appears for object files, including standard library headers, compiled with the -Ofast optimization flag (maybe some other flags but I haven't checked)

Minimal reproducible code

fileA.c:

#ifndef __attribute__ # define __attribute__(X) #endif #include <stdio.h> #include <stdlib.h> int foo() {}

fileB.c:

#ifndef __attribute__ # define __attribute__(X) #endif #include <stdio.h> #include <stdlib.h> int bar() {}

Command:

gcc -Ofast fileA.c fileB.c

Output of gcc -v

Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++,rust --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/issues --with-build-config=bootstrap-lto --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-libstdcxx-backtrace --enable-link-serialization=1 --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.2.1 20240910 (GCC)

GCC's __attribute__ is not a macro, so your #ifdef test fails in GCC, and probably in other compilers that emulate its attribute syntax. In that case you define your own macro with that (reserved) name, producing undefined behavior. That manifests as you saw, presumably by the mechanism of working nastiness on the standard headers #included afterward.

Collectives™ on Stack Overflow

Multiple definitions of glibc symbols when linking several static libraries with gcc

1 Answer 1

Minimal reproducible code

1 Comment

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Minimal reproducible code

1 Comment

Related