Boost 1.53 Upgrade Failed: error: "platform not supported"

[michaelld (Michael Dickens)]

Host is a MacBook Pro 15" retina mid-2012: 2.6 GHz Intel 4-Core i7; 8 GB DRAM. Using latest port from SVN trunk. Will attach build log. Nothing in Boost's bug tracker that I can find; not sure if this is a MacPorts or Boost issue.

[adfernandes (Andrew Fernandes)]

Looks like they've killed support for 32-bit builds on OS X. Homebrew is having the same problem.

From what I can see, the boost thread module does an explicit check and throws an "unsupported" error for OS X 32 bit builds.

Not sure what to do about this. If it is explicitly not supported, it is not supported, and no more 32-bit threading or universal builds.

Or patch to build everything but threads on 32-bit systems.

[adfernandes (Andrew Fernandes)]

Turns out it's the ​context module that's the problem. Judging by the jamfile, it should be supported, so I don't know why...

[ryandesign (Ryan Carsten Schmidt)]

Replying to adfernandes@…:

Not sure what to do about this. If it is explicitly not supported, it is not supported, and no more 32-bit threading or universal builds.

That would kill 32-bit-only ports that need boost. I only see three though: gnash (because xulrunner), poedit (because wxWidgets 2.8), hugin-app.

[michaelld (Michael Dickens)]

BTW> On my 64-bit native system, installing as -universal (just 64-bit) works. So, it seems to be the 32-bit part that's broken. Go Boost!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #38310.

[SlaunchaMan (Jeff Kelley)]

Cc Me!

[SlaunchaMan (Jeff Kelley)]

Cc Me!

[jdgleeson]

Cc Me!

[rlhamil]

Cc Me!

[dylanryan]

Cc Me!

[dylanryan]

Cc Me!

[dylanryan]

Cc Me!

( Sorry for the noise: Accidentally hit this in my history and it un-cc'd me for some reason... )

[adfernandes (Andrew Fernandes)]

Okay - anybody have a preferred way to handle this? I figure the options are as follows:

• disable 32-bit builds with an error (not good, since a lot of people build universal)
• diable the context module completely until this gets fixed (probably easiest, but will probably never get fixed)
• disable context only for 32-but builds (which means we can't use bjam's built-in support for universal binaries, so we have to fake it with lipo, but then the libboost_context will be empty...

Of course, the context module looks really interesting, so I don't really want to disable it.

If anyone wants to chime in, please feel free. There's a free ice cream cone in it for you if you can figure out why the jamfile is failing... :-)

[ryandesign (Ryan Carsten Schmidt)]

Is there an upstream bug report we can refer to?

[adfernandes (Andrew Fernandes)]

The closest I can find is ​this. However, the MacPorts issue is slightly different as the jamfile appears to be mis-classifying the build target.

My guess is that the jamfile for context does not handle universal builds correctly, since Mac OS is the only OS that builds all archs at the same time... but that's just a guess...

[Serge3leo (Serguei E. Leontiev)]

Cc Me!

[Serge3leo (Serguei E. Leontiev)]

Replying to adfernandes@…:

• diable the context module completely until this gets fixed (probably easiest, but will probably never get fixed)

Context new library introduced by Boost 1.53.0, IMHO may safe disabled.

sudo port edit boost

Insert "--without-libraries=context" switch

configure.args      --without-libraries=python \
                    --without-libraries=mpi \
                    --without-libraries=context \
                    --with-icu=${prefix}

Late need patch "libs/context/build/Jamfile.v2" for toolset darwin and universal binary

[cooljeanius (Eric Gallager)]

Cc Me!

[michaelld (Michael Dickens)]

Looks like what happened was a change in how the context module works between 1.52 and 1.53. In 1.52, context was provided both via cpp and asm; the asm version wasn't used when doing +universal on darwin because the "address-model" (being "32_64" [both 32 and 64 bit pointer sizes]) has no target associated with it (all of the targets are either 32 or 64) in the context's Jamfile.v2; the debug log shows Jam's output about this issue: "error: No best alternative for libs/context/build/asm_context_sources", and then reverting back to the cpp code.

In 1.53, there is just asm code, no cpp; hence, if there is no match in the Jamfile then nothing can be compiled because there is no backup cpp to revert to. The Jam script, as before, provides only 32 or 64 builds, no 32_64. Further, the toolset was changed from "gcc" to "darwin" between 1.52 and 1.53, which I think is heading in the correct direction but not quite there (though I haven't quite figured out the exact toolset being used).

I see 3 primary choices: (1) disable context, as per an above comment. (2) use the muniversal portgroup, compile separately as 32 and 64, then merge any binaries; hope that none of the other installed files are 32 or 64 specific. (3) copy the 1.52 cpp files and hack the Jamfile(s) to revert to them if/when there are no appropriate asm files.

[anddam (Andrea D'Amore)]

Cc Me!

[ttimo@…]

Cc Me!

[adfernandes (Andrew Fernandes)]

After some time for reflection, I think that removing the context library is not a good idea since it is a "core" library. In fact, I want to play with it myself now for some multiprocessor work...

Can someone tell me what the muniversal port group setting will do if it tries to merge libraries that exist for the x86_64 platform and a nonexistent file (for i386)? Does it just install the one file, or will it error?

This will be one l-o-n-g install compile time. Hmm... and difficulty for me to test, since I don't build universal...

[michaelld (Michael Dickens)]

Not as long as qt4-mac :) I usually build +universal, so I'm happy to test. I've never used muniversal, so I cannot say more there; I just know it exists and that it does the trick for a number of otherwise obstinate ports.

[ryandesign (Ryan Carsten Schmidt)]

Replying to adfernandes@…:

Can someone tell me what the muniversal port group setting will do if it tries to merge libraries that exist for the x86_64 platform and a nonexistent file (for i386)? Does it just install the one file, or will it error?

If a file exists in only one arch, it will be copied. If a file exists in more than one arch, they will be merged, or an error will be printed if they cannot be merged.

This will be one l-o-n-g install compile time. Hmm... and difficulty for me to test, since I don't build universal...

It shouldn't be difficult to test; just "sudo port install boost +universal". It may of course take some time to recompile the dependencies universal, but MacPorts will do so automatically, so all you have to do is wait.

[raimue (Rainer Müller)]

Cc Me!

[cooljeanius (Eric Gallager)]

Replying to michaelld@…:

Not as long as qt4-mac :)

Well that's not saying much. :-P

[Serge3leo (Serguei E. Leontiev)]

Replying to adfernandes@…:

After some time for reflection, I think that removing the context library is not a good idea since it is a "core" library. In fact, I want to play with it myself now for some multiprocessor work...

OK, second workaround: test this patch "patch-libs-context-130308-0.diff"

Copy it to directory "/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/boost/files"

sudo cp patch-libs-context-130308-0.diff /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/boost/files/.
sudo port edit boost

Add patch filename to:

patchfiles      patch-tools_build_v2_engine_src_build.sh.diff \
                patch-tools_build_v2_engine_src_build.jam.diff \
                patch-libs-context-130308-0.diff \
                patch-bootstrap.sh.diff

[Serge3leo (Serguei E. Leontiev)]

P.S.

I submit this bug and patch to upstream, see ​https://svn.boost.org/trac/boost/ticket/8266

Examples seems working

leom-3:example leo$ c++ -arch i386 -arch x86_64 -I/opt/local/include exit.cpp -L/opt/local/lib -lboost_context-mt
leom-3:example leo$ arch -i386 ./a.out 
size: 0x28
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return
leom-3:example leo$ arch -x86_64 ./a.out 
size: 0x58
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return
leom-3:example leo$ c++ -arch i386 -arch x86_64 -I/opt/local/include jump.cpp -L/opt/local/lib -lboost_context-mt
leom-3:example leo$ arch -i386 ./a.out 
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return
main: done
leom-3:example leo$ arch -x86_64 ./a.out 
main: call start_fcontext( & fcm, fc1, 0)
f1: entered
f1: call jump_fcontext( fc1, fc2, 0)
f2: entered
f2: call jump_fcontext( fc2, fc1, 0)
f1: return
main: done

[michaelld (Michael Dickens)]

Nice patch/solution for x86, Leo! I kick myself for not thinking of it ;) It works for me, too. Do we need a similar solution for older systems -- e.g., ppc +universal? Seems like a similar approach could be taken for them.

[adfernandes (Andrew Fernandes)]

Wow, Leo... completely awesome, thank you! (And thank you for only using your obvious superpowers only for good, not evil...) :-)

Building and testing now.

[adfernandes (Andrew Fernandes)]

r103856. Thanks to everyone for helping, especially Leo!

[Serge3leo (Serguei E. Leontiev)]

Replying to michaelld@…:

... Do we need a similar solution for older systems -- e.g., ppc +universal? Seems like a similar approach could be taken for them.

Sorry. For Mac OSX and "powerpc" or "combined" architecture needed:

1. Convert *ppc*_elf_gas.S files to *ppc*_macho_gas.S files;
2. Compile & test ppc32 may on VM with Snow Leopard, Xcode 3.6 and Rosetta;
3. But ppc64 needed real hardware;

IMHO the new library is not required on the old hardware. Just add "--without-libraries=context" argument for PPC

[jdgleeson]

You don't have any reports because I am the only Boost+G5 user in the universe, and I've been buried in coursework ;-)

I just sent an email to the Boost developer list saying I am interested in working on *ppc*_macho_gas.S files.

Unfortunately, I don't expect to be able to dig out from under my coursework for a couple more weeks. If Leo uses his superpowers in the meantime to whip up these files, I will not be disappointed. And I will happily test both ppc32 and ppc64 versions.

I vote +1 for "--without-libraries=context" argument for PPC

[jdgleeson]

I just created ticket:38339 for the issue on PPC

[fang@…]

Cc Me!