# Installation clobbers LDFLAGS

**URL:** <https://discourse.julialang.org/t/installation-clobbers-ldflags/90139>\
**Category:** New to Julia\
**Tags:** installation\
**Created:** [November 11, 2022, 11:50pm UTC](https://discourse.julialang.org/t/installation-clobbers-ldflags/90139 "2022-11-11T23:50:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![smartalecH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/smartalech/32/32379_2.png) [@smartalecH](https://discourse.julialang.org/u/smartalecH)\
**Post date:** [November 11, 2022, 11:50pm UTC](https://discourse.julialang.org/t/installation-clobbers-ldflags/90139/1 "2022-11-11T23:50:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![aramirezreyes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aramirezreyes/32/42573_2.png) [@aramirezreyes](https://discourse.julialang.org/u/aramirezreyes)\
**Post date:** [November 11, 2022, 11:55pm UTC](https://discourse.julialang.org/t/installation-clobbers-ldflags/90139/2 "2022-11-11T23:55:21Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![smartalecH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/smartalech/32/32379_2.png) [@smartalecH](https://discourse.julialang.org/u/smartalecH)\
**Post date:** [November 11, 2022, 11:56pm UTC](https://discourse.julialang.org/t/installation-clobbers-ldflags/90139/3 "2022-11-11T23:56:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![smartalecH](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/smartalech/32/32379_2.png) [@smartalecH](https://discourse.julialang.org/u/smartalecH)\
**Post date:** [November 14, 2022, 5:27pm UTC](https://discourse.julialang.org/t/installation-clobbers-ldflags/90139/4 "2022-11-14T17:27:36Z")

</div>

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

```julia
$(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…