boost library names are of the form libboost_foo-mt.a

[dave@…]

Code that links with boost doesn't build because -lboost_foo is not found.

And btw, what is the -mt for? boost libs on other platforms don't have these.

[cooljeanius (Eric Gallager)]

The "-mt" stands for "multi-threaded". It gets added by the +no_single variant to boost. If you want the un-suffixed versions of the library, install boost without the +no_single variant (i.e. change the "+" in front of the variant to a "-").

While this is a user error/misunderstanding here, it probably could have been avoided if the boost Portfile had cleared this up for users itself with a better variant description or something. Right now the variant description for +no_single just says:

[+]no_single: Disable building single-threaded libraries

It takes external knowledge about boost to realize that that variant description actually means that only libraries suffixed with -mt will be installed. It would probably be easier for the user if that were explicitly spelled out instead, either in that description, or in some notes. Also, the variants should probably be renamed to fit the MacPorts variant naming convention of not starting variants with "no_".

[cooljeanius (Eric Gallager)]

Cc Me!

[dave@…]

and the default configuration definitely should install both the -mt and non-mt variants.

[mf2k (Frank Schima)]

In the future, please fill in the Port field.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dave@…:

and the default configuration definitely should install both the -mt and non-mt variants.

The additional building of single-threaded libraries by default was deliberately disabled in r95845 in order to cut down build time. We could consider undoing that change, since we do have the precompiled binaries, which most users can use, so build time isn't an issue for most users.

[dave@…]

Or is it a bad idea to just link the mt name to the non-mt name?

[ryandesign (Ryan Carsten Schmidt)]

Replying to dave@…:

Or is it a bad idea to just link the mt name to the non-mt name?

Absolutely that would be a horrible idea. They have different names for a reason: they are not the same library.

[cooljeanius (Eric Gallager)]

Replying to ryandesign@…:

Replying to dave@…:

and the default configuration definitely should install both the -mt and non-mt variants.

The additional building of single-threaded libraries by default was deliberately disabled in r95845 in order to cut down build time. We could consider undoing that change, since we do have the precompiled binaries, which most users can use, so build time isn't an issue for most users.

I have +universal added to my variants.conf, and boost has not had a precompiled binary with the +universal variant since version 1.54, so I have found myself building boost from source a lot lately... Any idea why the buildbot built previous versions of boost with the +universal variant, but not more recent ones?

[ryandesign (Ryan Carsten Schmidt)]

Replying to egall@…:

Any idea why the buildbot built previous versions of boost with the +universal variant, but not more recent ones?

The only time the buildbot will build a port with a universal variant is if some port that is 32-bit only depends on it, and it will only be built when that 32-bit-only port is committed (in other words, it won't happen when boost is updated; it'll happen when the 32-bit port that depends on boost is updated). I don't see any ports that currently fit that criteria, except for povray in certain circumstances, so maybe some other port used to be 32-bit only and has since been upgraded to support 64-bit.

[ryandesign (Ryan Carsten Schmidt)]

Replying to dave@…:

and the default configuration definitely should install both the -mt and non-mt variants.

This is #38406, where you can read more about why that's maybe not a good idea.