Opened 10 years ago

Closed 10 years ago

#44118 closed defect (duplicate)

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

Reported by: dave@… Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.3.0
Keywords: Cc: cooljeanius (Eric Gallager)
Port: boost

Description

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.

Change History (10)

comment:1 Changed 10 years ago by cooljeanius (Eric Gallager)

The "-mt" stands for "multi-threaded". It gets added by the +no_single variant to boost.

Version 0, edited 10 years ago by cooljeanius (Eric Gallager) (next)

comment:2 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:3 Changed 10 years ago by dave@…

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

Last edited 10 years ago by dave@… (previous) (diff)

comment:4 Changed 10 years ago by mf2k (Frank Schima)

Port: boost added

In the future, please fill in the Port field.

comment:5 in reply to:  3 ; Changed 10 years ago by 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.

comment:6 Changed 10 years ago by dave@…

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

comment:7 in reply to:  6 Changed 10 years ago by 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.

comment:8 in reply to:  5 ; Changed 10 years ago by 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?

comment:9 in reply to:  8 Changed 10 years ago by 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.

comment:10 in reply to:  3 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: duplicate
Status: newclosed

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.

Note: See TracTickets for help on using tickets.