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
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
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,
$(dir $<)/configure $(CONFIGURE_COMMON) LDFLAGS="$(CXXLDFLAGS)" CPPFLAGS="$(CPPFLAGS)"
…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…