fix compiler option -static

[katietz]

Current compiler disables -static by removing its basic static libraries for libgcc (which is in many aspects not good, even for shared versions), and libstdc++. This leads to two facts:

1. we have a broken compiler, which lacks basic feature.
2. projects using static option for their build tools are failing to build. Most prominent project is as example qt

I agree that we don't want to encourage users to build static libraries, but we shouldn't ship here broken compilers for that. A better solution would be to specify in activation explicit a gcc spec file, which disables the usage of static in general.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[katietz]

Well, not that qt would picked it up there. Also by inspecting used _build_env/lib it wasn't showing up for me. But I used for this patch Ray's aarch64 branch on AnacondaRecipes/ctng-compilers-feedstock(bootstrapping) ... We ran into this issue by trying to build qt 5.15.0

[isuruf]

I think the correct fix here is to fix the line https://github.com/conda-forge/ctng-compilers-feedstock/blob/master/recipe/install-libgcc-devel.sh#L14 to not delete the static libraries. libgcc-devel is a runtime requirement of the compiler, so if a user installed the compiler, then they'd get libgcc.a. Not having libgcc.a in libgcc-ng means it is not downloaded by users not compiling anything.

[katietz]

yes, that makes sense. As we don't have to remove static libgcc, nor for developement static libstdc++.a either. I would have expected those libraries in the devel package too, but as they couldn't be found there, I assumed we would package them with ther shared variants.

[isuruf]

Wait, it's there. Here's the list of contents of libgcc-devel_linux-64.

lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtbegin.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtbeginS.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtbeginT.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtend.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtendS.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtfastmath.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtprec32.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtprec64.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/crtprec80.o
lib/gcc/x86_64-conda-linux-gnu/9.3.0/include/gcov.h
lib/gcc/x86_64-conda-linux-gnu/9.3.0/libgcc.a
lib/gcc/x86_64-conda-linux-gnu/9.3.0/libgcc_eh.a
lib/gcc/x86_64-conda-linux-gnu/9.3.0/libgcov.a

[katietz]

So it is not found in $PREFIX/lib itself ... what is pretty much what my fix tries to address. And we see that libstc++.a seems to be missing here.

[isuruf]

True, but the compiler itself knows to find libgcc.a in lib/gcc/x86_64-conda-linux-gnu/9.3.0/. Can you share a reproducer of the error?

[isuruf]

I haven't tried -static-libgcc, but I know that -static-libstdcxx works because I used it in a project a couple of weeks ago.

[katietz]

well a classical one would be something like this for libgcc.a: file: t.c int main() { return 0; } compiler: via 'gcc -o t t.c -static'

for c++: we will need to use something from libstdc++ file: t.cc

include

int main() { std::cout << "Hello world" << std::endl; return 0; } compile 'g++ -o t t.cc -static'

[katietz]

well, for libgcc it should work, but where it picks up static version of libstdc++? for sure not from $PREFIX/lib, and not from its default folder (as we saw). I agree that it worked in the past. We suspect that it is actually the removal of .a files in libgcc part, as that one from libstdc++ is there already for some time (year+).

[isuruf]

$CC -o t t.c -static-libgcc works for me. (gcc looks at lib/gcc/x86_64-conda-linux-gnu/9.3.0) $CXX -o t t.cc -static-libstdc++ works for me. (g++ looks at x86_64-conda-linux-gnu/lib. I agree that this is weird and should be in lib/gcc/x86_64-conda-linux-gnu/9.3.0, but it works nevertheless)

$CC -o t t.c -static does not because we are not shipping the static libc. Is this the issue that you are seeing?

[katietz]

So, I looked a bit more into detail of things done on boostrapping branch on AnacondaRecipes, and it seems to boil down that it removes 'rm -rf ${PREFIX}/${CHOST}/lib' by libgcc-devel.sh ... which is btw not done for libstdc++-devel ?

I am looking at the aarch64 target, and it uses instead lib64 ... which seems to be here the real issue. Anyway, please close this pr, I will come up with something new, if I identified the issue here for real.

[katietz]

$CC -o t t.c -static-libgcc works for me. (gcc looks at lib/gcc/x86_64-conda-linux-gnu/9.3.0) $CXX -o t t.cc -static-libstdc++ works for me. (g++ looks at x86_64-conda-linux-gnu/lib. I agree that this is weird and should be in lib/gcc/x86_64-conda-linux-gnu/9.3.0, but it works nevertheless)

$CC -o t t.c -static does not because we are not shipping the static libc. Is this the issue that you are seeing?

Yes, that might be the issue I see. I just saw in qt's build that it couldn't find -lstdc++ for static, but that might be a diagnostic not necessarily being true. This search path thing in our gcc toolchain is indeed a bit fishy ... I would expect that it fails for cases default lib is not "lib" but "lib64".

[isuruf]

I created https://github.com/conda-forge/linux-sysroot-feedstock/issues/35 for the libc.a issue.