cctools, ld64: Removing +llvm37 variant pulls in +llvm34 instead and toolchain becomes unstable on 10.6

[kenneth.f.cunningham@…]

The +llvm37 variants have been removed from cctools and ld64. This causes systems installed with +llvm37 (as per the current LibCxxOnOlderSystems instructions) to pull in +llvm34 versions of cctools and ld64 - which in my case at least, brought down the toolchain.

if {![variant_isset llvm33] && ![variant_isset llvm34] && ![variant_isset llvm38] && ![variant_isset llvm39] && ![variant_isset llvmdev]} {
    if {${os.major} >= 13} {
        default_variants +llvm38
    } elseif {${os.major} >= 10} {
        default_variants +llvm34
    } elseif {${os.major} >= 9} {
        # Using llvm-3.3 to break dependency cycle (https://trac.macports.org/ticket/52091)
        default_variants +llvm33
    }
}

Also, as there is no +llvm37 option, the current LibCxxOnOlderSystems instructions (which mostly reference +llvm37) aren't functional.

[jeremyhu (Jeremy Huddleston Sequoia)]

Please use +llvm38, +llvm39, or +llvmdev

I think you have a cached version of LibcxxOnOlderSystems because that page recommends using +llvm38.

[jeremyhu (Jeremy Huddleston Sequoia)]

Can you explain how +llvm34 "brought down the toolchain"? It should still function fine, just with some LTO functionality missing.

[kenneth.f.cunningham@…]

Hi Jeremy,

Can you explain how +llvm34 "brought down the toolchain"? It should still function fine, just with some LTO functionality missing.

Not really sure how it died...when ld64 upgraded with the +llvm34 variant, it started segfaulting on any attempts to link executables. Nothing I saw in the crash logs gave me a definite clue as to why. I couldn't properly get ld64 to roll back either.

Please use +llvm38, +llvm39, or +llvmdev

Check. Using +llvm38 now, on Snow Leopard, after the math.h fix I filed separately. Hopefully the other issue you mentioned with clang/llvm-3.8 on snow leopard (I believe it was something to do with i386 code building) won't be troublesome.

Best, Ken

[kenneth.f.cunningham@…]

I think you have a cached version of LibcxxOnOlderSystems because that page recommends using +llvm38.

You rolled that page back to clang-3.7 in most places after finding issues with clang-3.8 on SL, although indeed the page at the moment still says to set the variant to +llvm38 in (5). But I don't grok that -- Isn't it the case that the installed compiler and the default variant would need to match?

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok. I'll see if I can break it. Do you have any crash logs I can look at?

Note that +llvm38 doesn't actually require using macports-clang-3.8. You can continue to use macports-clang-3.7

[kenneth.f.cunningham@…]

Replying to jeremyhu@…:

Ok. I'll see if I can break it.

I installed LibCxxOnOlderSystems, but instead of +llvm38, I put +llvm37 in the variants thinking that was correct to go with clang-3.7. Also, perhaps of importance, when I was finished bootstrapping with clang-3.4, I deactivated it but did not fully uninstall it (thinking I would leave it deactivated but available to activate for another rebuild of clang-3.7 if needed). So that clang-3.4 was the bootstrap version, built against libstdc++.

The iteration of cctools and ld64 was the current version - 1.

Then when cctools and ld64 upgraded, they called in clang-3.4/llvm3-4, which reactivated the deactivated version, built ld64 (with libcxx=libc++ in the macports.conf and all other settings correct). Then the segfaults started.

Do you have any crash logs I can look at?

Stupidly, and for no good reason, I deleted them. Another user (ftp83) had a similar experience and his crash log is here <​http://pastebin.com/bzuez8Xp>. It's probably the same issue.

Note that +llvm38 doesn't actually require using macports-clang-3.8. You can continue to use macports-clang-3.7

Just when I think I am getting a good understanding of what I'm doing, you tell me something like this and I realize I know nothing :>

Ken

[jeremyhu (Jeremy Huddleston Sequoia)]

Then when cctools and ld64 upgraded, they called in clang-3.4/llvm3-4

I understand why llvm-3.4 would be pulled in, but why was clang-3.4? That doesn't make sense.

​http://pastebin.com/bzuez8Xp

Dang, that log's pretty useless =/ ... it looks like maybe an atexit handler is failing for some reason, maybe cxa_finalize gone wrong.

[kenneth.f.cunningham@…]

I understand why llvm-3.4 would be pulled in, but why was clang-3.4? That doesn't make sense.

You are correct - it was just llvm-3.4. Up to now, I have thought of them as an inseparable intertwined versioned pair, but I can see over your last several posts they are actually separate entities.

here's the log of exactly what happened during the upgrade process:

--->  Dependencies to be installed: llvm-3.4
--->  Activating llvm-3.4 @3.4.2_11
--->  Fetching distfiles for ld64-latest
--->  Verifying checksums for ld64-latest
--->  Extracting ld64-latest
--->  Applying patches to ld64-latest
--->  Configuring ld64-latest
--->  Building ld64-latest
--->  Staging ld64-latest into destroot
--->  Installing ld64-latest @264.3.102_2+llvm34
--->  Computing dependencies for ld64-latest
--->  Deactivating ld64-latest @264.3.102_1+llvm37
--->  Activating ld64-latest @264.3.102_2+llvm34

then I checked the following and and found the +llvm34 option installed:

$ port -v installed ld64*
The following ports are currently installed:
 ld64 @2_0-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' archs='x86_64'
 ld64 @2_0+ld64_136 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm34 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm37-llvm34 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_1+llvm37 platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_2+llvm34 (active) platform='darwin 10' archs='x86_64'

In retrospect, perhaps I should have just left everything as it was right at that point, BUT thinking that was very wrong, I tried to reactivate the +llvm37 variant.

sudo port activate ld64-latest @264.3.102_1+llvm37

$ sudo port activate ld64-latest @264.3.102_1+llvm37
--->  Computing dependencies for ld64-latest
--->  Deactivating ld64-latest @264.3.102_2+llvm34
--->  Activating ld64-latest @264.3.102_1+llvm37

then rechecked:

$ port -v installed ld64*
The following ports are currently installed:
 ld64 @2_0-ld64_127-ld64_136-ld64_236-ld64_97 (active) platform='darwin 10' archs='x86_64'
 ld64 @2_0+ld64_136 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm34 platform='darwin 10' archs='x86_64'
 ld64-136 @136_5+llvm37-llvm34 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_1+llvm37 (active) platform='darwin 10' archs='x86_64'
 ld64-latest @264.3.102_2+llvm34 platform='darwin 10' archs='x86_64'

and thought that looked right to me, but segfaulted.

So I tried this:

$ sudo port upgrade --enforce-variants ld64-latest +llmv37 -llvm34
Error: Your platform cannot be configured without LTO support in ld64.  Please enable one of the llvmXX variants, and try again.

and then -- after looking around in the portfile long enough to see the +llvm37 variant gone -- decided to start over with +llvm38 -- deleted all traces of clang*, llvm*, ld64*, and cctools*, and started over with success in the end.

[jeremyhu (Jeremy Huddleston Sequoia)]

Ok, as of r152166 r152167, you can replace the +llvm37 or +llvm38 from variants.conf with -llvm34 in order to "follow along" like newer OS versions.

[kenneth.f.cunningham@…]

Thanks, Jeremy.