Opened 3 months ago

Last modified 4 weeks ago

#58898 assigned defect

libcxx bootstrapping needs a method to upgrade to the +emulatedtls variant on 10.6 and less

Reported by: kencu (Ken) Owned by: jeremyhu (Jeremy Huddleston Sequoia)
Priority: Normal Milestone:
Component: ports Version:
Keywords: snowleopard leopard tiger Cc: jmroot (Joshua Root), mojca (Mojca Miklavec), cjones051073 (Chris Jones)
Port: libcxx

Description

during automatic bootstrapping of 10.6 and less, libcxx is installed as a first step, building with clang-3.4.

As clang-3.4 does not support building libcxx +emulatedtls, libcxx is first built without +emulatedtls. The process then leads to the installation of clang-5.0 or greater, and these compilers do support building libcxx +emulatedtls.

The libcxx Portfile will build libcxx +emulatedtls if a suitable compiler is installed that can build it, but it presently requires a manual rebuild to force the upgrade.

For a fully functional older system, this upgrade should be automatic.

One option might be to put a revision increase by 1 in the Portfile, in the block that tests if libcxx +emulatedtls can be built and enables it if so.

Change History (19)

comment:1 Changed 5 weeks ago by kencu (Ken)

Owner: kencu deleted

comment:2 Changed 5 weeks ago by mf2k (Frank Schima)

Cc: jeremyhu removed
Owner: set to jeremyhu

comment:3 Changed 4 weeks ago by kencu (Ken)

jeremy is not going to fix this. At this point in time I might as well consider owning this port, even though I deleted myself from owning this ticket a week ago :}

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:4 Changed 4 weeks ago by mojca (Mojca Miklavec)

Cc: mojca added

comment:5 Changed 4 weeks ago by cjones051073 (Chris Jones)

Cc: cjones051073 added

comment:6 Changed 4 weeks ago by kencu (Ken)

so the revision +1 idea if a clang >= 5.0 is found is one way to force the update.

could also exist a libcxx-bootstrap port.

Maybe that is more appropriate?

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:7 Changed 4 weeks ago by kencu (Ken)

the revision +1 approach will get pretty confused by the buildbot's portindex. That's probably not a good idea, in the end...

comment:8 Changed 4 weeks ago by cjones051073 (Chris Jones)

I also would be wary of an approach that plays games with the revision... seems like a recipe for all sorts of problems.

Last edited 4 weeks ago by cjones051073 (Chris Jones) (previous) (diff)

comment:9 Changed 4 weeks ago by cjones051073 (Chris Jones)

I think a dedicated 'bootstrap' version of libcxx that the first bootrap phase of the clang builds use, is the way to go. It would then later on get replaced by the main libcxx build.

comment:10 Changed 4 weeks ago by kencu (Ken)

shame we can't depend on a port variant..

So libcxx on < 10.7 would have to depend on libcxx-bootstrap. Tha's simple enough. But it would also have to depend on some clang >= 5.0, and that is circular.

unless clang can be satisfied by libcxx-bootstrap. which it can.

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:11 Changed 4 weeks ago by cjones051073 (Chris Jones)

I was more thinking of something like.... clang-3.4 declares a path like dependency, something like path:lib/something.dylib:libcxx-bootstrap so when it is first built it triggers the installation of libcxx-bootstrap. Then, later on, when clang5 etc. are built they keep the port:libcxx dep. Finally, libcxx would have to have some logic added to forcibly remove libcxx-bootstrap when it is built/installed, so effectively it replaces it.

Last edited 4 weeks ago by cjones051073 (Chris Jones) (previous) (diff)

comment:12 Changed 4 weeks ago by kencu (Ken)

It's complex. clang-3.4 can't depend on any version of libcxx.

comment:13 Changed 4 weeks ago by kencu (Ken)

libcxx just overwrites to previous, so doesn't have to forcibly remove it ... but then you cannot tell which libcxx is installed with a path dependency either...

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)

comment:14 Changed 4 weeks ago by cjones051073 (Chris Jones)

Hmmmm. How about adding a libcxx-bootstrap sub-port to libcxx, that does everything identically apart from it does not enable emulatedtls whereas libcxx does. Basically give libcxx and libcxx +emulatedtls different port names so you can then more easily tell which is currently installed....

comment:15 Changed 4 weeks ago by cjones051073 (Chris Jones)

b.t.w. you say clang-3.4 does not itself depend on libcxx. But, something in the dep tree must be the thing that first triggers its installation ? Could you not then make that depend on path:lib/something.dylib:libcxx-bootstrap ?

comment:16 in reply to:  14 ; Changed 4 weeks ago by kencu (Ken)

Replying to cjones051073:

Hmmmm. How about adding a libcxx-bootstrap sub-port to libcxx, that does everything identically apart from it does not enable emulatedtls whereas libcxx does.

Chris - that is exactly what I suggested :>

But -- you can't tell which one is installed with a path dep.

I would work on this, but history tells me Josh will parachute in with the fix any second now...

comment:17 Changed 4 weeks ago by kencu (Ken)

Now -- if I actually was a computer science major, perhaps I would have folded the emulated_tls objects in somewhere else, like perhaps in ld64 and adding in tapi, like Iains appears to have done here <https://github.com/iains/tapi/commit/aeab0de3e9ec61c97d8f3cd86928983eba59de49> .

But I did it the way I understood how to do it, using existing libcxx tools, so we have the setup we have.

Of interest, it is pretty simple to build libcxx +emulated_tls with gcc with some modest hackery <https://github.com/kencu/macports-ports/commits/libcxxfixupgcc> . That's what I do on PowerPC, but I knew/know that is not a method acceptable to MacPorts, so never bothered to propose it here.

comment:18 in reply to:  16 Changed 4 weeks ago by cjones051073 (Chris Jones)

Replying to kencu:

Replying to cjones051073:

Hmmmm. How about adding a libcxx-bootstrap sub-port to libcxx, that does everything identically apart from it does not enable emulatedtls whereas libcxx does.

Chris - that is exactly what I suggested :>

But -- you can't tell which one is installed with a path dep.

I guess not with path... But we could have each of the flavours of libcxx install some special info file which says which it is (via the file name for instance), and then use that somehow to determine if libcxx-bootstrap is in fact installed, and thus needs to be forcibly replaced with libcxx....

I would work on this, but history tells me Josh will parachute in with the fix any second now...

Last edited 4 weeks ago by cjones051073 (Chris Jones) (previous) (diff)

comment:19 Changed 4 weeks ago by kencu (Ken)

You're right -- there is a special include file in /usr/include that I only include with +emulated_tls variant. We could path dep on that.

Edit: nope, I'm wrong. I just expose a new function in the header, but it's not a totally new header. So we would still need a breadcrumb, as Chris said.

Last edited 4 weeks ago by kencu (Ken) (previous) (diff)
Note: See TracTickets for help on using tickets.