c++functionlinkerlinker-errorsmultiple-definition-error

"Multiple definition" error when statically linking


I'm trying to compile a link together these simple example programs:

main.cpp:

#include "server.hpp"

int main()
{

}

server.hpp:

#ifndef SERVER_HPP
#define SERVER_HPP

#include <boost/asio.hpp>

class Server
{
    boost::asio::io_context context;

    void listen();
};

#endif

server.cpp:

#include "server.hpp"

void Server::listen()
{
    static boost::asio::ip::tcp::acceptor acceptor {
        context,
        {boost::asio::ip::tcp::v4(), 1000}
    };
}

I'm compiling all this with gcc 13.1:

g++ -static-libgcc -static-libstdc++ -std=c++23 .\main.cpp .\server.cpp -lws2_32

However, for some reason I cannot understand, I get this linker error:

D:/Programmi/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: D:/Programmi/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../lib\libstdc++.a(tinfo.o):(.text$ZNKSt9type_infoeqERKS+0x0): multiple definition of `std::type_info::operator==(std::type_info const&) const'; C:\Users\jayok\AppData\Local\Temp\cc4dUKMC.o:server.cpp:(.text$ZNKSt9type_infoeqERKS[ZNKSt9type_infoeqERKS]+0x0): first defined here collect2.exe: error: ld returned 1 exit status

If I make the body of the "listen" function empty, or if I make the linking not-static by omitting those arguments, however, this error no longer appears, and the compilation is successful.


Solution

  • So, could it be a compiler bug?

    Indeed, this seems to be a GCC — or rather libstdc++ — related issue.

    The reason there's nothing much to find about it is that it only seems to occur with c++23 and static linking, so probably not very many of us have hit it.

    How do I signal it to the developer?

    From the libstdc++ docs:

    Implementation Bugs

    Information on known bugs, details on efforts to fix them, and fixed bugs are all available as part of the GCC bug tracking system, under the component “libstdc++”.

    Here, it's been reported now, actually. (Couldn't find it initially, but came back with the update.)

    Workaround:

    If you can do without RTTI, then compiling with -fno-rtti can save your build.