[MacPorts] #18894: Internal libboost dependency failure at reference time.

[MacPorts]

#18894: Internal libboost dependency failure at reference time.
---------------------------------+------------------------------------------
  Reporter:  trog24@…            |       Owner:  macports-tickets@…                   
      Type:  defect              |      Status:  closed                               
  Priority:  Normal              |   Milestone:  Port Bugs                            
 Component:  ports               |     Version:  1.7.0                                
Resolution:  wontfix             |    Keywords:                                       
      Port:                      |  
---------------------------------+------------------------------------------

Comment(by braden@…):

 Maybe it is; maybe it isn't. I'm not suggesting that Boost should be
 patched to use `pkg-config`. I'm pointing out that the situation in Boost
 points to a general problem and I'm asking the question, "What would
 MacPorts do if Boost ''did'' use `pkg-config`?"

 So, as I've said, there are bigger questions being raised here that
 deserve answers. If answering those questions is being tracked somewhere
 else, that's fine (but a link seems appropriate).

 Broadly, "How, in general, should MacPorts approach this difference
 between the GNU and Darwin linkers?" If building Boost (or any other
 library that exhibits such a pattern) with -flat_namespace would allow
 greater consistency, I don't think that should be so quickly
 dismissed--'''especially in light of the guidance `pkg-config` users are
 getting regarding `Requires.private`'''. This isn't just a Boost problem.
 What's happening there could easily happen elsewhere. That it hasn't been
 noticed (much) could very well be due to the limited deployment of
 `Requires.private`; but you should expect that to change.

 It's also worth noting that adding a library to LIBS when building
 openvrml (or many other packages with multiple linker outputs) will result
 in a lot of bogus dependencies. That is, doing this will make
 '''everything''' depend on the added library; when in fact only one of the
 linker outputs (in openvrml's case) actually needs it.

-- 
Ticket URL: <http://trac.macports.org/ticket/18894#comment:16>
MacPorts <http://www.macports.org/>
Ports system for Mac OS