-ffunction-sections -fdata-sections

[stackTom]

Does llvm-mingw for windows support -ffunction-sections and -fdata-sections? If it does, do we need these flags for Windows? Assume I have compiled a library with llvm-mingw and wish to use MSVC's /Gy and /OPT:REF (in order to only statically link those functions which my executable uses from the library). I asked a similar question here: msys2/MINGW-packages#6808

[mstorsjo]

Yes, -ffunction-sections and -fdata-sections should work with llvm-mingw.

To achieve the same as /OPT:REF, pass -Wl,--gc-sections when linking.

[stackTom]

Yes, -ffunction-sections and -fdata-sections should work with llvm-mingw.

To achieve the same as /OPT:REF, pass -Wl,--gc-sections when linking.

It appears to work and compile correctly, but the generated libraries don't seem to be compatible with MSVC linker. It complains that the library is corrupt. The same issue occurs when using mingw64 gcc.

[mstorsjo]

Yes, -ffunction-sections and -fdata-sections should work with llvm-mingw.
To achieve the same as /OPT:REF, pass -Wl,--gc-sections when linking.

It appears to work and compile correctly, but the generated libraries don't seem to be compatible with MSVC linker. It complains that the library is corrupt. The same issue occurs when using mingw64 gcc.

So you are compiling something using mingw tools, and then linking using mingw tools or the MSVC linker? You'll need to provide a minimal reproducible example for me to be able to act on this.

Do note that you can't (in general) mix object files (or static libraries) built in mingw mode and MSVC mode; code built in mingw mode needs to be linked into a dll with a mingw linker before you can interface with it with MSVC tools. (The fact that it might seem to work in small testcases does not imply that it works in general.)

[stackTom]

Yes, -ffunction-sections and -fdata-sections should work with llvm-mingw.

To achieve the same as /OPT:REF, pass -Wl,--gc-sections when linking.

It appears to work and compile correctly, but the generated libraries don't seem to be compatible with MSVC linker. It complains that the library is corrupt. The same issue occurs when using mingw64 gcc.

So you are compiling something using mingw tools, and then linking using mingw tools or the MSVC linker? You'll need to provide a minimal reproducible example for me to be able to act on this.

Do note that you can't (in general) mix object files (or static libraries) built in mingw mode and MSVC mode; code built in mingw mode needs to be linked into a dll with a mingw linker before you can interface with it with MSVC tools. (The fact that it might seem to work in small testcases does not imply that it works in general.)

The libraries I am creating are GNU GMP, MPFR, and MPC. They are compiled and linked with LLVM-MINGW. If I create static libraries and then use them in visual studio 2019, everything works great. If I compile with -ffunction-sections and -fdata-sections, visual studio begins to complain that the static libraries are corrupt. The same happens with the regular mingw-gcc, so the issue isn't limited to llvm-mingw, and there might be nothing to be done about it.

[mstorsjo]

The libraries I am creating are GNU GMP, MPFR, and MPC. They are compiled and linked with LLVM-MINGW. If I create static libraries and then use them in visual studio 2019, everything works great. If I compile with -ffunction-sections and -fdata-sections, visual studio begins to complain that the static libraries are corrupt. The same happens with the regular mingw-gcc, so the issue isn't limited to llvm-mingw, and there might be nothing to be done about it.

Aha, ok, that explains it.

Yes, this is a clear case that the warranty doesn't cover - the fact that it happened to work for you before adding these options was sheer luck, and even if it does seem to link correctly there could be cases where the e.g. CRT headers and import libraries subtly disagree and you'd run into to hard to diagnose bugs at runtime.

In particular, -ffunction-sections makes comdat sections for the functions, and GNU tools use a different scheme for handling comdat sections than MSVC tools and only using some bits out of the COFF spec, together with some conventions of their own.

[stackTom]

The libraries I am creating are GNU GMP, MPFR, and MPC. They are compiled and linked with LLVM-MINGW. If I create static libraries and then use them in visual studio 2019, everything works great. If I compile with -ffunction-sections and -fdata-sections, visual studio begins to complain that the static libraries are corrupt. The same happens with the regular mingw-gcc, so the issue isn't limited to llvm-mingw, and there might be nothing to be done about it.

Aha, ok, that explains it.

Yes, this is a clear case that the warranty doesn't cover - the fact that it happened to work for you before adding these options was sheer luck, and even if it does seem to link correctly there could be cases where the e.g. CRT headers and import libraries subtly disagree and you'd run into to hard to diagnose bugs at runtime.

In particular, -ffunction-sections makes comdat sections for the functions, and GNU tools use a different scheme for handling comdat sections than MSVC tools and only using some bits out of the COFF spec, together with some conventions of their own.

I see, that makes sense. So, do you recommend compiling these libraries dynamically instead of statically in order to eliminate these hard to diagnose bugs at runtime? Or are these bugs unavoidable when mixing mingw gcc/llvm code with MSVC.

[mstorsjo]

I see, that makes sense. So, do you recommend compiling these libraries dynamically instead of statically in order to eliminate these hard to diagnose bugs at runtime? Or are these bugs unavoidable when mixing mingw gcc/llvm code with MSVC.

Building libraries dynamically is the generally recommended, safe way of handling mixing mingw and and msvc code.