Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#38298 closed defect (fixed)

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

Reported by: michaelld (Michael Dickens) Owned by: adfernandes (Andrew Fernandes)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: ryandesign (Ryan Carsten Schmidt), SlaunchaMan (Jeff Kelley), jdgleeson, rlhamil, dylanryan, Serge3leo (Serguei E. Leontiev), cooljeanius (Eric Gallager), anddam (Andrea D'Amore), ttimo@…, raimue (Rainer Müller), fang@…
Port: boost

Description

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.

Attachments (2)

boost_1.53_upgrade_main.log (1.0 MB) - added by michaelld (Michael Dickens) 12 years ago.
patch-libs-context-130308-0.diff (2.1 KB) - added by Serge3leo (Serguei E. Leontiev) 12 years ago.

Download all attachments as: .zip

Change History (38)

Changed 12 years ago by michaelld (Michael Dickens)

Attachment: boost_1.53_upgrade_main.log added

comment:1 Changed 12 years ago by 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.

comment:2 Changed 12 years ago by 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...

comment:3 in reply to:  1 Changed 12 years ago by 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.

comment:4 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

comment:5 Changed 12 years ago by 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!

comment:6 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: SlaunchaMan@… added

Has duplicate #38310.

comment:7 Changed 12 years ago by SlaunchaMan (Jeff Kelley)

Cc: SlaunchaMan@… removed

Cc Me!

comment:8 Changed 12 years ago by SlaunchaMan (Jeff Kelley)

Cc: SlaunchaMan@… added

Cc Me!

comment:9 Changed 12 years ago by jdgleeson

Cc: jdgleeson@… added

Cc Me!

comment:10 Changed 12 years ago by rlhamil

Cc: rlhamil@… added

Cc Me!

comment:11 Changed 12 years ago by dylanryan

Cc: dylanryan@… added

Cc Me!

comment:12 Changed 12 years ago by dylanryan

Cc: dylanryan@… removed

Cc Me!

comment:13 Changed 12 years ago by dylanryan

Cc: dylanryan@… added

Cc Me!

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

Last edited 12 years ago by dylanryan (previous) (diff)

comment:14 Changed 12 years ago by 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... :-)

comment:15 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Is there an upstream bug report we can refer to?

comment:16 Changed 12 years ago by 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...

comment:17 Changed 12 years ago by Serge3leo (Serguei E. Leontiev)

Cc: leo@… added

Cc Me!

comment:18 in reply to:  14 Changed 12 years ago by 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

comment:19 Changed 12 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:20 Changed 12 years ago by 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.

Last edited 12 years ago by michaelld (Michael Dickens) (previous) (diff)

comment:21 Changed 12 years ago by anddam (Andrea D'Amore)

Cc: and.damore@… added

Cc Me!

comment:22 Changed 12 years ago by ttimo@…

Cc: ttimo@… added

Cc Me!

comment:23 Changed 12 years ago by 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...

comment:24 Changed 12 years ago by 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.

comment:25 in reply to:  23 Changed 12 years ago by 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.

comment:26 Changed 12 years ago by raimue (Rainer Müller)

Cc: raimue@… added

Cc Me!

comment:27 in reply to:  24 Changed 12 years ago by cooljeanius (Eric Gallager)

Replying to michaelld@…:

Not as long as qt4-mac :)

Well that's not saying much. :-P

Changed 12 years ago by Serge3leo (Serguei E. Leontiev)

comment:28 in reply to:  23 Changed 12 years ago by 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
Last edited 12 years ago by Serge3leo (Serguei E. Leontiev) (previous) (diff)

comment:29 Changed 12 years ago by 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
Last edited 12 years ago by Serge3leo (Serguei E. Leontiev) (previous) (diff)

comment:30 Changed 12 years ago by 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.

comment:31 Changed 12 years ago by 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.

comment:32 Changed 12 years ago by adfernandes (Andrew Fernandes)

Resolution: fixed
Status: newclosed

r103856. Thanks to everyone for helping, especially Leo!

comment:33 in reply to:  30 Changed 12 years ago by 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

P.S.

Both, upstream Boost and MacPorts, don't compile on PowerPC Mac OSX. But we don't have any reports about this.

Last edited 12 years ago by Serge3leo (Serguei E. Leontiev) (previous) (diff)

comment:34 Changed 12 years ago by 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

comment:35 Changed 12 years ago by jdgleeson

I just created ticket:38339 for the issue on PPC

comment:42 Changed 11 years ago by fang@…

Cc: fang@… added

Cc Me!

Note: See TracTickets for help on using tickets.