Opened 12 years ago
Closed 11 years ago
#36654 closed defect (wontfix)
mpich2 @1.5_2 fails to compile with LLVM clang
Reported by: | texas-swift (Spencer Swift) | Owned by: | eborisch (Eric A. Borisch) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.1.2 |
Keywords: | Cc: | jeremyhu (Jeremy Huddleston Sequoia), goodell@… | |
Port: | mpich2 |
Description
When trying to install mpich2 @1.5_2 under Mountain Lion Mac OS X 10.8.2 with Xcode 4.5.1 and the latest command line tools, the build fails when clang throws a segmentation fault. I did try configuring with configure.compiler=llvm-gcc-4.2, but that did not fix the problem. I was able to build when I cleaned again and configured with configure.compiler=apple-gcc-4.2.
I am attaching the main logfile from a failed build with configure.compiler=llvm-gcc-4.2.
Attachments (3)
Change History (30)
Changed 12 years ago by texas-swift (Spencer Swift)
comment:1 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | changed from macports-tickets@… to eborisch@… |
---|---|
Port: | mpich2 added |
comment:2 Changed 12 years ago by eborisch (Eric A. Borisch)
Can you try building with clang-3.1? The (native) clang build succeeds on Snow Leopard, but I haven't tried ML. This might just have to be resolved with a compiler blacklist. In the log, clang seg-faulted while making the actual libs with no other messages.
comment:3 Changed 12 years ago by texas-swift (Spencer Swift)
Sure, if you can help me understand how to do that. Another configure.compiler option I presume?
comment:4 follow-up: 6 Changed 12 years ago by eborisch (Eric A. Borisch)
sudo port install mpich2 +clang31
This will install clang31 and all of its deps, so it may take a while. I have a ML machine I can test it on this weekend if you'd rather not.
comment:5 Changed 12 years ago by texas-swift (Spencer Swift)
Honestly, I have a busy day and weekend. If you can get to it this weekend, that would be great. Otherwise, I can attempt next week.
comment:6 Changed 12 years ago by amadeus24
Replying to eborisch@…:
sudo port install mpich2 +clang31
This will install clang31 and all of its deps, so it may take a while. I have a ML machine I can test it on this weekend if you'd rather not.
Had same problem with ML and XCODE 4.5.1 installed.
"sudo port install mpich2 +clang31" works fine.
comment:7 Changed 12 years ago by eborisch (Eric A. Borisch)
I had it build on ML this past weekend, but I haven't had a chance to get back to it to check what version of Xcode is on that machine.
comment:8 Changed 12 years ago by eborisch (Eric A. Borisch)
Can you update to the latest (1.5_4) and give it a shot.? There main change is disabling alloca at config time. 1.5_4 builds fine for me on a matching (OS / Xcode) setup.
comment:9 Changed 12 years ago by eborisch (Eric A. Borisch)
Scratch that. I spoke too soon; I had upgraded Xcode, but not the command line tools.
I had this clang: (which was building just fine)
Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix
after upgrade I get this clang: (which segfaults as advertised)
Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn) Target: x86_64-apple-darwin12.2.0 Thread model: posix
I'm laying this one on clang... Now I just need to figure out blacklists. Can I blacklist on the specific version, or do I just blanket say 'no clang for you (on ML)?'
+clang31 variant builds fine, BTW. :)
comment:10 Changed 12 years ago by eborisch (Eric A. Borisch)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in r99297.
comment:11 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
This isn't clang segfaulting. It's the linker. Please do not just blacklist compilers without at least filing a bug report for the underlying problem. Issues won't resolve on their own, and using old compilers is not a long-term solution.
Furthermore, you should be using the compiler version checking that Ryan added rather than xcode version checking.
Reopening as this is not fixed yet. (#37121).
Please attach a crash report.
comment:12 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Attachment: | ld_2012-12-16-093442_tifa.crash added |
---|
crash log
comment:13 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
It looks like a radar was never filed for this, so I just filed one. Too bad one wasn't filed back in October... =/
<rdar://problem/12889845>
comment:14 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Please try rebuilding using ld64 changes in r100587 using +clang31.
Assuming that works, we can then cleanup the mpich2 Portfile a bit.
comment:15 Changed 12 years ago by eborisch (Eric A. Borisch)
I will try this out tomorrow night. Sorry if I didn't triage this to your satisfaction, but I don't have much free time to put in to chasing down crashes in new versions of compilers.
I don't believe the compiler version checking was in place yet when I made these changes, but hopefully with your fixes we can remove most of the checks.
Thanks for your help!
comment:16 Changed 12 years ago by eborisch (Eric A. Borisch)
That works; thanks! I'll update the portfile to blacklist clang >= 421.11.66 (to be updated with an upper bound eventually.)
comment:17 Changed 12 years ago by eborisch (Eric A. Borisch)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:18 Changed 12 years ago by eborisch (Eric A. Borisch)
Work-around to enable using system clang/ld from http://lists.macosforge.org/pipermail/macports-dev/2012-December/021299.html implemented in r100702 / r100703.
comment:19 Changed 12 years ago by eborisch (Eric A. Borisch)
Cc: | jeremyhu@… added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
With the latest changes (r101065) to the mpich package to building dynamic libraries, we've run into another issue with clang (possibly ld64). I hope to poke more at it later this evening, but I may blacklist clang again for a while...
comment:20 follow-up: 22 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
That's probably not another issue. It's probably the same issue.
comment:21 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
If you can attach a crash report, I'll take a look at it to see if it's the same... if not, I'll try to take a look again when I get some spare time.
Changed 12 years ago by eborisch (Eric A. Borisch)
Attachment: | ld_2013-01-04-223628_Monolith.crash added |
---|
ld.crash
comment:22 Changed 12 years ago by goodell@…
Replying to jeremyhu@…:
That's probably not another issue. It's probably the same issue.
@jeremyhu@…: Do you have a small-ish test case or description of the details of the problem that I could use to reproduce the issue without building all of MPICH? I would like to add a configure test for this case to MPICH itself, but I'm having trouble creating a small test case. For example, the simple test in https://gist.github.com/4498137 is insufficient. My limited understanding of your patch to ld64 is that it's affecting PC-relative TLS code generated by the linker, but it's not obvious to me how to induce the compiler/linker to generate this sort of code.
AFAIK there's no way for me to see your radar...
comment:24 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Yeah, that's the same issue. You'll need to stop using the system ld until Apple releases a version of Xcode with the fix.
I don't have a reduced test, sorry.
comment:25 follow-up: 26 Changed 12 years ago by goodell@…
My limited testing indicates that this has been fixed by Xcode 4.6.
comment:26 Changed 12 years ago by jeremyhu (Jeremy Huddleston Sequoia)
comment:27 Changed 11 years ago by jmroot (Joshua Root)
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
r103204 made mpich2 replaced_by mpich.
mpich2 llvm compilation log