llvm 2.8 buildroot leaky

[howarth@…]

The llvm build root in v2.8 is leaky because of a flaw in Makefile.rules. The attached patch (which has been committed to llvm svn for 2.9) fixes this by making sure that LD.Flags precedes LDFLAGS. Otherwise, if -L/opt/local/lib is passed to LDFLAGS, the current llvm 2.8 Makefile.rules allows that path to override those set for the newly built libraries in the buildroot.

[howarth@…]

Makefile.rules patch to insure LD.Flags are used.

[howarth@…]

Note that this issue is triggered when building a newer version of llvm with an older version installed. The older installed libs are used for linkage incorrectly during the build.

[mfeiri]

Maybe I understand this wrong, but I don't see how this can apply to us in general: We don't include the build root in the llvm package any more. Other ports are expected to use their own "make" infrastructure. And, yes, even the clang port uses a separate build root.

An upgrade from llvm2.7 to llvm2.8 within macports might be the only way to trigger this bug, right? Several months have passed since this upgrade and I think I checked various upgrade scenarios without noticing any issues. Did you really observe this issue?

PS: We have seen linking issues in the past and worked around these issues by using the "install_name_tool" in a post-destroot phase. Maybe this masked/solved the effect of the problem you describe?

[howarth@…]

I suspect you will see the same problem in MacPorts (as I saw in fink with my llvm-clang packaging). Previously, the LDFLAGS and LD.Flags were handled inappropriately. If you already had installed an earlier version of llvm in /opt/local/lib and passed -L/opt/local/lib on LDFLAGS for the build of the new llvm, there would be misc build failures. These were always suppressed by uninstalling the older release of llvm. The problem was due to the fact that LDFLAGS was placed in front of LD.Flags in the LINK command in Makefile.rules. This caused a linkage on the new executables against the old llvm libraries in /opt/local/lib instead of the newly built ones. See...

​http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/013760.html ​http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/013778.html ​http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/013783.html ​http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/013784.html

Of course if MacPorts never had a llvm package before llvm 2.8, you won't see the problem. It would manifest itself if llvm 2.7 was installed and llvm 2.8 was built. Note you won't see this problem with llvm 2.9 because my patch is committed upstream for that release.

[howarth@…]

Also note that I am using the term buildroot in the more general sense of not linking against installed versions of the shared libraries but only against the newly built ones. It is obvious that LDFLAGS in front of LD.Flags will not allow that to happen.

[howarth@…]

This change is...

---

r127152 | echristo | 2011-03-06 23:25:12 -0500 (Sun, 06 Mar 2011) | 4 lines

Prepend LD.Flags before LDFLAGS to avoid overriding necessary paths.

Patch by Jack Howarth.

---

in llvm svn upstream.

[mfeiri]

Thanks for the explanation! Since you got this fixed upstream I feel inclined to just wait for 2.9. Any objections?

[howarth@…]

According to...

​http://trac.macports.org/log/trunk/dports/lang/llvm/Portfile

llvm 2.8 isn't the first version of llvm in MacPorts. The current package should have build issues if anyone with the previous MacPorts llvm 2.7 package attempts to upgrade to it.

[mfeiri]

I was wondering why we didn't get any reports about this issue and why I haven't noticed any problem during my own tests (I did test various upgrade scenarios). So I spent some time trying to reproduce this issue by uninstalling and cleaning llvm, downgrading the Portfile to r70474, installing llvm@2.7_2 through macports, upgrading the Portfile to the latest version, and then upgrading to this latest version of llvm. Everything went fine.

After reading your patch and your explanation I would agree that there could be a issue. And your patch shouldnt cause any trouble, so we could include it anyway. But I am hesitant to force a (possibly multi-hour) rebuild of llvm on all current users of this port without a good reason to do so.

I don't have time to investigate this in more detail. I am tempted to close this reports as "worksforme". The new version 2.9 of llvm (including your fix) should arrive within weeks anyway.