Opened 11 years ago

Last modified 3 weeks ago

#38406 new enhancement

boost: disable no_single by default

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

Description

I am preparing a new Portfile for htcondor (http://research.cs.wisc.edu/htcondor/) that will depend on the single-threaded Boost libraries, which requires boost to be built with the no_single variant disabled. Since Boost takes so very long to build, could the no_single variant be disabled by default, so that the buildbots build the single-threaded libraries as well as the multi-threaded ones?

Change History (6)

comment:1 Changed 11 years ago by adfernandes (Andrew Fernandes)

Owner: changed from macports-tickets@… to adfernandes@…
Status: newassigned

Hello - I'm reasonably familiar with condor, and I guess that I'd want to ask if you're sure that the mac version requires the single-threaded version? (As in "it really needs it because of the wonky things that condor does to the thread and run states of a process", not (and I'm sorry if this sounds snotty) "it requires single-threaded because that's how the condor packagers assumed would be simplest".

The Mac ABI and libraries are different from Linux because almost everything is multithreaded by default; it's actually rather tricky to build "from the low-level guts only single-threaded code". In fact, if you search for _REENTRANT in the system headers, you'll find that it is only used in

  • the c++/4.2.1/bits runtime (in the gthr-* threading includes)
  • the ldap header
  • libexslt
  • libxml
  • libxslt
  • net-snmp
  • the system php includes
  • and the gamma and log-gamma functions (and variants) in math.h.

All of these are actually hold-overs from Linux or gnu systems, or where they optimize to have one control structure rather than a shared control structure.

To actually answer your question/request :-) what ends up being shorter compile times for condor ends up being long for others. In particular, choosing a python version requires extra compilation.

But really, for 99% of people, I think that the pre-compiled Port will be used. So... I can remove the no_static and no_single variants if other people will weigh in with their opinions. (I added these default variants before the MacPorts build system went live, so they may be obsolete now...)

Opinions, anyone?

comment:2 in reply to:  1 Changed 11 years ago by lpsinger (Leo Singer)

Replying to adfernandes@…:

Hello - I'm reasonably familiar with condor, and I guess that I'd want to ask if you're sure that the mac version requires the single-threaded version? (As in "it really needs it because of the wonky things that condor does to the thread and run states of a process", not (and I'm sorry if this sounds snotty) "it requires single-threaded because that's how the condor packagers assumed would be simplest".

I didn't look deeply into this because I was afraid that the answer might turn out to be that the single-threaded boost libraries are needed for condor_compileing. I can certainly add a patch to the port to force the multithreaded libraries, and see what happens.

comment:3 Changed 11 years ago by mf2k (Frank Schima)

Cc: adfernandes@… removed
Type: requestenhancement
Version: 2.1.3

A 'request' is only for requesting new ports. This is an 'enhancement'.

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

Owner: changed from adfernandes@… to macports-tickets@…
Status: assignednew

comment:5 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Has duplicate #44118.

Subports might be a good solution. Leave the boost port installing only the multithreaded libraries, and make a new boost-st subport to install just the singlethreaded libraries.

comment:6 Changed 3 weeks ago by cooljeanius (Eric Gallager)

Cc: cooljeanius added
Note: See TracTickets for help on using tickets.