Installation clobbers LDFLAGS

I’m trying to build Julia on some complicated infra with rather strict tooling. I’m trying to do things the “right way” and build all of the listed dependencies (i.e. no system dependency flags).

When I get to the part that builds patchelf, it has trouble configuring. Specifically, it compiles a test requiring glibc, but it when it tries to run said test, it dies because it’s trying to reference the wrong glibc version.

Normally this shouldn’t be an issue, as I have the rpath set in my LDFLAGS. Looking at the configure log, I notice that the LDFLAGS are empty. This is odd, because my CFLAGS, CXXFLAGS, PATH, etc. are all fine.

Does the install process deliberately clobber the LDFLAGS during this step?

For reference I’m using the julia 1.8.2 “full” tarball release on intel hardware, centos7, gcc11, glibc2.34.

I have seen this before and I noticed I had an active conda environment and I forgot. It turned out that conda does that with the environment variables. Not sure if that is your case but it may be worth to check!

Thanks @aramirezreyes! I don’t have any active conda env (or any other virtual env) but great suggestion!

Ok so it appears that the patchelf Makefile actually resets the LDFLAGS using a new environment variable, CXXLDFLAGS:


…which indeed clobbers all the other LDFLAGS previosuly set (e.g. in CONFIGURE_COMMON). I’ve never seen this “approach” before, and I don’t know why it’s needed. My guess is there were some library conflicts back in the day and this is how they resolved the compilation process?

Either way, this should probably be documented (at least in the debugging section of the linux build instructions).

Now I’m getting a similar problem with openblas. When it tries to detect the architecture, it references the wrong libc (as before). Unfortunately, I don’t see any “clobbering” of the LDFLAGS in openblas’s deps Makefile… so this one is going to be tricky to debug. I’m getting some weird behavior when I build in parallel (-j) too… so I need to look into that…