Summary: | Portage: install_qa_check function trips over special variables in Mach-O install_names | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Charles Davis <cdavis5x> |
Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | OS X | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to fix this bug |
Description
Charles Davis
2011-09-04 18:10:58 UTC
Created attachment 285543 [details, diff]
Patch to fix this bug
odd, I'm sure @executable_path is already ignored (In reply to comment #2) > odd, I'm sure @executable_path is already ignored It is, but by that time the function has already produced the '.install_name_check_failed' file, which eventually causes Portage to bail (c.f. misc-functions.sh, line 940). ehm... an install_name can be relative? install_name references can be @whatever now, but the install_name itself (id) not. llvm has special code in the ebuild to kill the @executable_path crap, so I don't understand why this is an issue (it has ~ppc-macos keyword). (In reply to comment #4) > ehm... an install_name can be relative? Yeah. Where do you think the install_name references come from? > > install_name references can be @whatever now, but the install_name itself (id) > not. Why not? It seems to work fine for LLVM. (By the way, Wine wants to do this too, but they fail at it because they use install_name_tool to change it after linking, but there's not enough room in the load command to change it.) Most of the LLVM devs work for Apple, so I think they know a thing or two about how Mach-O works :). (In reply to comment #5) > llvm has special code in the ebuild to kill the @executable_path crap, so I > don't understand why this is an issue (it has ~ppc-macos keyword). The svn (version 9999) ebuild doesn't work quite right because the version on the dylib is 3.0svn, not 9999. The code actually skips over it because libLLVM-9999.dylib doesn't exist. (In reply to comment #6) > (In reply to comment #4) > > ehm... an install_name can be relative? > Yeah. Where do you think the install_name references come from? Set from a build-system that knows exactly what it's doing. You can't just make a relative install name and expect every application/library to obey that. > > install_name references can be @whatever now, but the install_name itself (id) > > not. > Why not? It seems to work fine for LLVM. (By the way, Wine wants to do this > too, but they fail at it because they use install_name_tool to change it after > linking, but there's not enough room in the load command to change it.) -max_pad_header_names or something, I thought we emitted that one by default. On libraries, it can never be the right thing, unless you're in a bundle, perhaps. Since Gentoo Prefix is not about bundles, but traditional UNIX filesystem layout, these refs are bad/broken by design. > Most of the LLVM devs work for Apple, so I think they know a thing or two about > how Mach-O works :). Yes, and they know how what they're creating is packaged. Which is absolutely not like Gentoo Prefix. I doubt they even know what it is. > (In reply to comment #5) > > llvm has special code in the ebuild to kill the @executable_path crap, so I > > don't understand why this is an issue (it has ~ppc-macos keyword). > The svn (version 9999) ebuild doesn't work quite right because the version on > the dylib is 3.0svn, not 9999. The code actually skips over it because > libLLVM-9999.dylib doesn't exist. Ohw. Well don't use those versions anyway. 2.9 is broken as hell as well, so you best stick to 2.8. LLVM is another typical example of an Apple-style project, which happens to hardcodedly only work on vanilla Apple systems in the first place. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #4) > > > ehm... an install_name can be relative? > > Yeah. Where do you think the install_name references come from? > > Set from a build-system that knows exactly what it's doing. You can't just > make a relative install name and expect every application/library to obey that. > > > > install_name references can be @whatever now, but the install_name itself (id) > > > not. > > Why not? It seems to work fine for LLVM. (By the way, Wine wants to do this > > too, but they fail at it because they use install_name_tool to change it after > > linking, but there's not enough room in the load command to change it.) > > -max_pad_header_names or something, I thought we emitted that one by default. It's -headermax_pad_install_names. And we do? Huh. I did not know that. I'm familiar with Wine outside of Gentoo because I work on it. (Go ahead, look at the Git history. Grep for my name.) And I know for a fact that they don't pass it on their own. That's why I brought that up. > > On libraries, it can never be the right thing, unless you're in a bundle, > perhaps. Since Gentoo Prefix is not about bundles, but traditional UNIX > filesystem layout, these refs are bad/broken by design. So the real problem is that LLVM is setting this at all. I'll see what I can do; I'm also an LLVM developer, you know :). A related problem is that LLVM doesn't obey the various fine-grained directory settings from the configure script. It assumes they're all relative to the prefix that it was given. > > > Most of the LLVM devs work for Apple, so I think they know a thing or two about > > how Mach-O works :). > > Yes, and they know how what they're creating is packaged. Which is absolutely > not like Gentoo Prefix. I doubt they even know what it is. I filed a bug on LLVM Bugzilla about Clang's behavior inside of a Gentoo prefix (in particular, how it barfs on Gentoo's ld64 version string). I have gotten absolutely no response from them about that. So I see what you mean. > > > > (In reply to comment #5) > > > llvm has special code in the ebuild to kill the @executable_path crap, so I > > > don't understand why this is an issue (it has ~ppc-macos keyword). > > The svn (version 9999) ebuild doesn't work quite right because the version on > > the dylib is 3.0svn, not 9999. The code actually skips over it because > > libLLVM-9999.dylib doesn't exist. > > Ohw. Well don't use those versions anyway. 2.9 is broken as hell as well, so > you best stick to 2.8. In what ways? Maybe we can get them fixed for 3.0. (By the way, I use trunk myself, because I'm an LLVM developer.) > > -max_pad_header_names or something, I thought we emitted that one by default. > It's -headermax_pad_install_names. And we do? Huh. I did not know that. I'm > familiar with Wine outside of Gentoo because I work on it. (Go ahead, look at > the Git history. Grep for my name.) And I know for a fact that they don't pass > it on their own. That's why I brought that up. We as in Gentoo Prefix. However, I lied. We don't. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-alt/trunk/toolchain-prefix-wrapper/ld/darwinplugin.c?revision=1638&view=markup > > On libraries, it can never be the right thing, unless you're in a bundle, > > perhaps. Since Gentoo Prefix is not about bundles, but traditional UNIX > > filesystem layout, these refs are bad/broken by design. > So the real problem is that LLVM is setting this at all. I'll see what I can > do; I'm also an LLVM developer, you know :). > > A related problem is that LLVM doesn't obey the various fine-grained directory > settings from the configure script. It assumes they're all relative to the > prefix that it was given. I made a remark about the complex build-system in the ebuild where I install_name_tool the libs and bins. I noticed it's complex, and hence chose to work around, rather than fix it ;) Still, Gentoo Prefix is not the regular target for any LLVM/Apple developer, I'd suppose. > > > Most of the LLVM devs work for Apple, so I think they know a thing or two about > > > how Mach-O works :). > > > > Yes, and they know how what they're creating is packaged. Which is absolutely > > not like Gentoo Prefix. I doubt they even know what it is. > I filed a bug on LLVM Bugzilla about Clang's behavior inside of a Gentoo prefix > (in particular, how it barfs on Gentoo's ld64 version string). I have gotten > absolutely no response from them about that. So I see what you mean. Ohw, do you have a bug-ref? It takes a lot more to get llvm/clang to "behave" as there's even a file that hardcodes what to do with CHOSTs and include paths (it takes the Xcode SDKs) and more. I appreciate the efforts spent on it! > > Ohw. Well don't use those versions anyway. 2.9 is broken as hell as well, so > > you best stick to 2.8. > In what ways? Maybe we can get them fixed for 3.0. (By the way, I use trunk > myself, because I'm an LLVM developer.) I see. Well, on Linux linking is totally fubared because gcc is no longer used to perform the link. LLVM devs assumed that gcc just calls ld without any extra arguments or something, which of course isn't true. Chances are big they have solved this in the meantime. (In reply to comment #9) > I made a remark about the complex build-system in the ebuild where I > install_name_tool the libs and bins. I noticed it's complex, and hence chose > to work around, rather than fix it ;) > Still, Gentoo Prefix is not the regular target for any LLVM/Apple developer, > I'd suppose. Yeah. I don't build LLVM inside of my Prefix because linking is horribly broken (due to the bug I linked below). > > Ohw, do you have a bug-ref? http://llvm.org/PR8339 > It takes a lot more to get llvm/clang to "behave" as there's even a file that > hardcodes what to do with CHOSTs and include paths (it takes the Xcode SDKs) > and more. I appreciate the efforts spent on it! [...] > > > > Ohw. Well don't use those versions anyway. 2.9 is broken as hell as well, so > > > you best stick to 2.8. > > In what ways? Maybe we can get them fixed for 3.0. (By the way, I use trunk > > myself, because I'm an LLVM developer.) > > I see. Well, on Linux linking is totally fubared because gcc is no longer used > to perform the link. LLVM devs assumed that gcc just calls ld without any > extra arguments or something, which of course isn't true. Chances are big they > have solved this in the meantime. Yeah. As you've seen, the Clang driver is a huge mess. It's just hack after hack after hack to make the whole thing work out of the box on every Linux distro under the sun--at least, every one they know about. And it gets worse all the time. They don't even know what switches they need to pass to ld(1) on Gentoo. Hell, I'm not even sure they know that Gentoo exists! (It's not listed as a 'LinuxDistro' in that named enum.) In the short term, I can add Gentoo to this mess. But long term, we really need something better. This can't go on. They all know this, too, but nobody's willing to do the work to fix this (c.f. http://clang.llvm.org/UniversalDriver.html). |