On Thu, 20 Jul 2023, Thiago Macieira wrote:
On Wednesday, 19 July 2023 23:48:43 PDT Martin Storsjö wrote:
Switching with those flags works, as long as you're building a C-only
executable and linking libgcc statically (and not linking in any static
libraries that were built for another CRT). I'm pretty sure that libstdc++
touches lots of the things that have a differing ABI. A shared linked
libgcc will use the CRT that the toolchain was built with - although I'm
not sure if libgcc shares any CRT objects across the DLL boundary (whether
it is a real issue or just messy).
Thanks, Martin.
I was aware of this, but thanks for expanding on who it's really a binary-
incompatible choice.
For $DAYJOB project[1], we build the compiler itself and the libraries we
need, linking statically to all of them.... except libmingw & libwinpthread. I
need to check what those import and if they are binary-compatible.
Yeah, as there's so many different ABI affecting choices especially around
here, building all the libraries yourself is definitely the recommended
way to go IMO as well.
So are you saying that you're building your app with a non-default CRT
selected with the -mcrtdll option?
If you use the GCC -mcrtdll option for picking a non-default CRT, it would
work unless you're also linking, even statically, a toolchain-provided
libstdc++ though. I'm pretty sure that at least some parts of libstdc++
touch things that have a differing ABI, even if most things might seem to
work.
The msys2-carried old patch only switches what library to link against,
but a recently upstreamed one,
https://github.com/gcc-mirror/gcc/commit/453cb585f0f8673a5d69d1b420ffd4b3f53aca00,
also sets matching flags for at least picking the right definitions from
headers as well. The CRT switching flag from that commit, plus recompiling
everything (and staying away from libstdc++) should generally achieve the
same as using a purpose-configured toolchain.
The libmingw* parts (libmingw32.a and libmingwex.a) are intended to be
CRT-agnostic - I'm not aware of any parts in them relying on things with a
differing ABI or interface. A statically linked libgcc also probably is
fine. For libwinpthread, I'm not sure though.
// Martin
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
