fastparquet-2024.11.0-gfbf-2023a.eb fails with "C compiler cannot create executables"

[sassy-crick]

Dear all
whilst trying to build fastparquet-2024.11.0-gfbf-2023a.eb on RHEL-8.8 and Rocky-8.9, with the Rocky build inside a container, the build fails with the following error message in the EasyBuild log file

hecking for x86_64-unknown-linux-gnu-gcc... gcc
   checking whether the C compiler works... no
[ ... ]
configure: error: in `/dev/shm/jsassman/fastparquet/2024.11.0/gfbf-2023a/cramjam/cramjam-2.9.0/target/release/build/isal-sys-dec7c49f999ee0e3/out/isa-l':
   configure: error: C compiler cannot create executables
   See `config.log' for more details

Checking config.log reveals:

configure:3980: gcc -O3 -ffunction-sections -fdata-sections -fPIC -m64 -O2 -ftree-vectorize -march=native -fno-math-errno -I/rds/easybuild/dev/apps/software/FFTW/3.3.10-GCC-12.3.0/include -
I/rds/easybuild/dev/apps/software/FlexiBLAS/3.3.1-GCC-12.3.0/include -I/rds/easybuild/dev/apps/software/FlexiBLAS/3.3.1-GCC-12.3.0/include/flexiblas -static conftest.c -lm -lpthread >&5
/rds/easybuild/dev/apps/software/binutils/2.40-GCCcore-12.3.0/bin/ld: cannot find -lm: No such file or directory
/rds/easybuild/dev/apps/software/binutils/2.40-GCCcore-12.3.0/bin/ld: cannot find -lpthread: No such file or directory
/rds/easybuild/dev/apps/software/binutils/2.40-GCCcore-12.3.0/bin/ld: cannot find -lc: No such file or directory

I think that is exactly the same error which has been noted in PR #21869
As @Micket commented the problem is the -static .

What would be the way forward here? I would be in favour of patching that out, if that is working, unless there is a good reason not to do so.

[Micket]

either

1. we consider glibc-static to be a requirement on the build host OS, just like we require glibc-devel to be there.
2. we add a osdependencies for glibc-static on this easyconfig (and any others that also happen to statically link stuff)
3. patch this particular thing to make it not attempt static linking.

Static linking everything with -static is very rare. I don't think i've encountered this in any other easyconfig i've built, and as a maintainer i've built a ton for just testing.

I'm fine with patching it out for this particular thing, but it's indirectly done via rust, so i calling configure-make during one of it's packages, so I doubt it's easy.

[pavelToman]

It seems the problem is in cramjam?
But it should work with shared libs:
milesgranger/cramjam#172
milesgranger/cramjam#171

Gonna debug this as soon as Ugent clusters will be up again

[pavelToman]

When I install cramjam locally by pip it creates only cramjam.cpython-312-x86_64-linux-gnu.so in lib/python/site-packages/cramjam and if I run ldd on this lib it returns:

linux-vdso.so.1 (0x00007ffcb013b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5c3c7ae000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5c3c7a9000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5c3c7a4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5c3c6bb000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5c3c6b6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c3c4a2000)
/lib64/ld-linux-x86-64.so.2 (0x00007f5c3cd4e000)

[Micket]

Is it the internal configure step that checks for "working compiler" that attempts to statically link. Whether it actually tries to build the final project statically i dont know.

[boegel]

This worked for us because we have glibc-devel installed:

$ rpm -qf /usr/lib64/libpthread.a
glibc-devel-2.34-100.el9_4.4.x86_64