boost 1.53 multithreaded

[sjmackenzie]

It would seem that the packaged boost libraries are not multithreaded as the files don't have the appended 'mt'.

How does one get the multithreaded version of boost 1.53? Is there a parameter I need to pass into nix-env if so what is it?

Also I need to get --with-c++11 support.

[vcunat]

There's a parameter and it's enabled by default.

EDIT: for muti-threading. Adding an option for c++11 will be easy and non-intrusive.

[vcunat]

Is there any reason why we shouldn't have c++11 support by default? @peti ?

[peti]

No, I wouldn't know any reason to have C++11 features disabled - on the contrary!

[sjmackenzie]

okay, so the main issue is 'mt', the application I'm trying to build a nixpkg for requires boost to have mt. how do I enable this?

[vcunat]

It is enabled by default.

[sjmackenzie]

after using cmake and passing in the Boost_INCLUDEDIR and BOOST_LIBRARYDIR the debug output complains that the boost libs needed are not found, despite the LIBRARYDIR being correct. I recall building boost by the jam method and it generating a number of different files for one item (say threading) they had different appended bits. whereas these nix builds don't seem to conform.

please try build github.com/mozart/mozart2 I'd love to know how you can get that to build

[viric]

On Sat, Jul 27, 2013 at 01:00:21PM -0700, Stewart Mackenzie wrote:

after using cmake and passing in the Boost_INCLUDEDIR and BOOST_LIBRARYDIR the debug output complains that the boost libs needed are not found, despite the LIBRARYDIR being correct. I recall building boost by the jam method and it generating a number of different files for one item (say threading) they had different appended bits. whereas these nix builds don't seem to conform.

please try build github.com/mozart/mozart2 I'd love to know how you can get that to build

Maybe this package has a bad check for boost.

Boost can be installed so the libs have a pattern in the lib name showing how it is built ("-gd-mt-gcc48-..."), or without any pattern at all. We use the last approach; maybe your package expects boost installed with the pattern?

Because I'm also quite sure we build them with mt.

[shlevy]

Maybe we should symlink the appropriately-patterned names?

On Jul 27, 2013, at 17:37, viric notifications@github.com wrote:

On Sat, Jul 27, 2013 at 01:00:21PM -0700, Stewart Mackenzie wrote:

after using cmake and passing in the Boost_INCLUDEDIR and BOOST_LIBRARYDIR the debug output complains that the boost libs needed are not found, despite the LIBRARYDIR being correct. I recall building boost by the jam method and it generating a number of different files for one item (say threading) they had different appended bits. whereas these nix builds don't seem to conform.

please try build github.com/mozart/mozart2 I'd love to know how you can get that to build

Maybe this package has a bad check for boost.

Boost can be installed so the libs have a pattern in the lib name showing how it is built ("-gd-mt-gcc48-..."), or without any pattern at all. We use the last approach; maybe your package expects boost installed with the pattern?

Because I'm also quite sure we build them with mt. — Reply to this email directly or view it on GitHub.

[sjmackenzie]

Simlinking the different patterned names to these correctly compiled matching names without patterns sounds like a good way forward. Though boost jam creates IIRC about 4 different files, each compiled differently with different naming patterns, is the suggestion to link each patterned name to the same library?

[peti]

Some build systems assume that all Boost installations use the tagged layout, so that all libraries have these "-gd-mt-gcc48-something" suffixes. As far as I know, our Boost expression has an taggedLayout argument that can be set to true if desired. Just pass

boost.override { taggedLayout = true; }

instead of boost to the package you're trying to build.

[peti]

Maybe we should symlink the appropriately-patterned names?

The logic that determines these tagged libraries names is really weird. I would not want to re-implement that logic in Nix.

[viric]

On Sun, Jul 28, 2013 at 05:06:51AM -0700, Peter Simons wrote:

Maybe we should symlink the appropriately-patterned names?

The logic that determines these tagged libraries names is really weird. I would not want to re-implement that logic in Nix.

It's quite usual not to have the tags on unix. They are most meaningful on platforms like windows, I think.

I vote for fixing the single program among dozens that doesn't know how to find them.

[sjmackenzie]

It's quite usual not to have the tags on unix. They are most meaningful on platforms like windows, I think.

Well many of these programs aim for cross-platform support. So developers now say: I already support Mac, most Linux distros and windows, shall I support nixos? They probably wont support it. Boost is a major library and many programs use it.

Standard make is easy to get these different naming conventions in place, but for the likes of these modern day build systems such as cmake (becoming more prevalent) you immediately kill any boost+cmake combo.

[viric]

On Sun, Jul 28, 2013 at 05:21:49AM -0700, Stewart Mackenzie wrote:

It's quite usual not to have the tags on unix. They are most meaningful on platforms like windows, I think.

Well many of these programs aim for cross-platform support. So developers now say: I already support Mac, most Linux distros and windows, shall I support nixos? They probably wont support it. Boost is a major library and many programs use it.

Standard make is easy to get these different naming conventions in place, but for the likes of these modern day build systems such as cmake (becoming more prevalent) you immediately kill any boost+cmake combo.

Do you mean that boost+cmake doesn't work in nixpkgs? We have dozens of cmake programs finding boost just fine, since many years.

[sjmackenzie]

Hi Peter,

I just wish to clarify.

Just pass

boost.override { taggedLayout = true; }

instead of boost to the package you're trying to build.

Pardon my ignorance, nix-env -i boost.override { taggedLayout = true; } doesn't work. Is there some other approach of doing as you specified?

^S

[sjmackenzie]

Do you mean that boost+cmake doesn't work in nixpkgs? We have dozens of cmake programs finding boost just fine, since many years.

Excellent, could you point out? I want to examine the src and see what is going on.

[viric]

On Sun, Jul 28, 2013 at 05:39:32AM -0700, Stewart Mackenzie wrote:

Do you mean that boost+cmake doesn't work in nixpkgs? We have dozens of cmake programs finding boost just fine, since many years.

Excellent, could you point out? I want to examine the src and see what is going on.

For example, many KDE programs use cmake and boost: pkgs/desktops/kde-4.* .

This should bring more programs though: $ grep -R 'cmake._boost|boost._cmake' *

Regards, Lluís.

[sjmackenzie]

Do you mean that boost+cmake doesn't work in nixpkgs? We have dozens of cmake programs finding boost just fine, since many years.

For example, many KDE programs use cmake and boost: pkgs/desktops/kde-4.* .

This should bring more programs though: $ grep -R 'cmake._boost|boost._cmake' *

Okay so I'm looking for a cross-platform application (especially with windows support) that uses boost+cmake. (I should have been clear earlier, the constraints are cross-platform+boost+cmake), sadly nothing came up from your grep command except all my mozart-oz stuff.

^S

[viric]

On Sun, Jul 28, 2013 at 05:59:23AM -0700, Stewart Mackenzie wrote:

Do you mean that boost+cmake doesn't work in nixpkgs? We have dozens of cmake programs finding boost just fine, since many years.

For example, many KDE programs use cmake and boost: pkgs/desktops/kde-4.* .

This should bring more programs though: $ grep -R 'cmake._boost|boost._cmake' *

Okay so I'm looking for a cross-platform application (especially with windows support) that uses boost+cmake. (I should have been clear earlier, the constraints are cross-platform+boost+cmake), sadly nothing came up from your grep command except all my mozart-oz stuff.

Here: applications/audio/yoshimi/default.nix applications/graphics/freecad/default.nix applications/graphics/hugin/default.nix applications/graphics/openimageio/default.nix applications/misc/bibletime/default.nix applications/misc/blender/default.nix applications/networking/p2p/ktorrent/default.nix applications/office/calligra/default.nix applications/office/ledger/3.0.nix applications/office/scribus/default.nix applications/video/dvswitch/default.nix desktops/kde-4.8/kdepim-runtime.nix desktops/kde-4.8/support/akonadi/default.nix desktops/kde-4.10/kdepim-runtime.nix desktops/kde-4.10/support/akonadi/default.nix development/interpreters/hiphopvm/default.nix development/libraries/CGAL/default.nix development/libraries/caelum/default.nix development/libraries/clucene-core/2.x.nix development/libraries/cppnetlib/default.nix development/libraries/gstreamer/qt-gstreamer/default.nix development/libraries/indilib/default.nix development/libraries/libktorrent/default.nix development/libraries/mygui/svn.nix development/libraries/mygui/default.nix development/libraries/ogrepaged/default.nix development/libraries/vigra/default.nix development/libraries/pcl/default.nix games/blobby/default.nix games/flightgear/default.nix games/privateer/default.nix games/rigsofrods/default.nix games/spring/default.nix games/spring/springlobby.nix games/stuntrally/default.nix games/widelands/default.nix tools/filesystems/xtreemfs/default.nix tools/filesystems/grive/default.nix

[vcunat]

I often find useful tricks in package sources from other distros -- mainly Gentoo, Fedora, Arch, and Ubuntu/Debian. Most things can be done the same way, also one gets inspiration for some useful patches not accepted upstream.

[peti]

@vcunat, coming back to your earlier question: what exactly do you mean by "enabling C++11 features"? Do you mean that we should pass the appropriate -std flag to g++ when compiling boost?

[vcunat]

No, I meant the mentioned --with-c++11 configure flag.

[peti]

I tried to find any documentation about that flag, but I could not. Does anyone know which part of the boost build supports it?

/tmp/boost_1_54_0 $ ./bootstrap.sh --with-c++11
error: unrecognized option: --with-c++11
Try `./bootstrap.sh --help' for more information.

/tmp/boost_1_54_0 $ grep -R -- '--with-c++11' .

/tmp/boost_1_54_0 $ grep -R -- 'with-c++11' .

/tmp/boost_1_54_0 $ 

[sjmackenzie]

For example, if you wanted to install boost on a mac via brew you would do brew install boost --with-c++11 anyway this was just a precautionary. As the mozart-oz platform uses c++11. So I wanted to try get information whether nixos has boost c++11 support.

So doing the "fixing the single program among dozens that doesn't know how to find them." The simplest way would just be to create tagged simlinks to the tagless boost libraries?

[peti]

@sjmackenzie, where can I find information about this --with-c++11 flag? It doesn't seem to be defined in the Boost source code. Am I missing something?

[sjmackenzie]

hmmm apologies for the confusion, it seems --with-c++11 is brew specific : https://github.com/mxcl/homebrew/pull/19141 read the comments.

[vcunat]

Ah. But to me this seems to do only clang-specific changes. We use gcc by default almost everywhere AFAIK.

[peti]

I'm closing this issue, because it seems to have run into a dead end.