Boost::coroutine issues with standalone and non-standalone

Just pulled the coroutine hpp files from the non standalone case and these headers work fine for compile.

Can we find out the source of the included boost::coroutine and any patches applied?

Just pulled the coroutine hpp files from the non standalone case

how do I do that?

<uri>http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux-20100119.tar.bz2</uri>

ah, thanks!

looks like we can use [~Phoenix Linden]'s package manager:

$ cd $SOURCE_DIR

$ scripts/install.py boost

$ sudo cp -r libraries/include/boost/coroutine /usr/include/boost-1_41/boost/ # destination path might be different for you

$ scripts/install.py --uninstall boost

I found the source and tried to use them. But failed then tried the ones from LL. They worked indicating that they defentelly been patched by LL.

I believe this boost library is entirely hpp so nothing to compile, so I guess us packagers can just package it up as a boost-coroutine package, and we can even diff right off the publicized source against the LL source to see the changes.

Brad, where does this boost header comes from if it's not boost standard?
In any case, I think you should read Robin and Techwolf notes and give us your view on this.

we based our coroutine package on boost-coroutine-2009-12-01.tar.gz found here

we furthermore apply this patch to it.

Thanks Brad. One question though: is that bitbucket hg repo available from outside? I don't think it is by default (it shouldn't) so you may want to either attach that patch here or make that repo publicly available.

It's on bitbucket.org. It's intentionally publicly availible.

This same error happens non-standalone build on version 3313 from https://svn.secondlife.com/svn/linden/projects/2010/snowglobe/trunk

See related e-mail: https://lists.secondlife.com/pipermail/opensource-dev/2010-April/001617.html

I updated this jira since the error is exactly the same with or without the --standalone option.

Until there are updated boost packages, here is a patch for this that Lynx Linden posted to opensource-dev a while ago. It's pretty much the same as Brad's patch, but applies cleanly:
boost_coroutine_lynx_linden_patch.txt

When doing a non-standalone build, apply after the boost package is extracted to the build tree. Should be applied from libraries/include/.

Raised priority, since this is also happening with the pre-built boost from svn (depending on GCC version?)

On gcc 4.3 and 4.4 both. Patch works pretty good - should get applied to svn.

See comment for patch.

This also affects http://svn.secondlife.com/svn/linden/branches/2010/viewer-external applying the patch provided does fix it though. Should a separate VWR- be filed?

@Drew: no need to file a VWR: Brad will pick up that one and fix internally, then it'll make its way to viewer-external shortly.

I'm a little confused here: this issue is only affecting Linux 64 builds, right?

While I'm at it, I looked at the boost libs pointed to by install.xml (the ones LL builds and recommends for building):

• Windows: boost-1.39.0-windows-20100219.tar.bz2: the boost patch is applied in the boost lib
• Darwin (Mac): boost-1.39.0-darwin-20100222a.tar.bz2: the patch is not applied there (with no ill effect though)

I'm wondering why we have this difference between Mac and Windows. Intentional?

Merov, the patch is also missing from boost-1.39.0-linux-20100222a.tar.bz2 (currently in install.xml for linux32).

gcc 4.1 works without the patch (e.g. LL builds,) but gcc 4.4 (and 4.3 ?) need this patch to build.

On Linux this affects any build with gcc 4.4: 32bit, 64bit, standalone and default builds.

This is a larger problem for standalone builders, since they will need to install both boost::coroutine AND to patch it with this patch

OK, I'm punting to post 2.0 since it doesn't hamper the production of binaries off parabuild and since there is a patch attached for gcc 4.4 devs (though I understand it's suboptimal).

We will get that fixed as part of the Autobuild project which will make creating new clean 3rd party libs binary packages much more manageable and done in an open way.

Taking - I don't see any reason to not fix-up the linux32 package.

fixed in snowglobe2 trunk

Thanks Tofu!
For the record, this was done in Snowglobe 2.0:
http://svn.secondlife.com/trac/linden/changeset/3440

New Changeset:
http://hg.lindenlab.com/brad/viewer-auto-tests/changeset/be9c7abcaa61
SNOW-611 / SNOW-505 FIXED boost::coroutines headers broken for newish GCC versions.

New Changeset:
http://bitbucket.org/merov_linden/viewer-development-features/changeset/4f0fa4ebd9db
SNOW-611 / SNOW-505 FIXED boost::coroutines headers broken for newish GCC versions.