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

MacPorts noreply at macports.org
Mon Apr 6 17:05:45 PDT 2009


#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 mcalhoun@…):

 Replying to [comment:16 braden@…]:
 > Maybe it is; maybe it isn't. I'm not suggesting that Boost should be
 patched to use `pkg-config`.
 Sorry, I misunderstood.

 > 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.[[BR]]
 > If answering those questions is being tracked somewhere else, that's
 fine (but a link seems appropriate).
 I am unaware of this issue being tracked anywhere else, but this
 particular ticket is abut one particular problem.[[BR]]
 As you say, it might be just the first indication of more problems, but I
 do not think we need to keep this ticket open[[BR]]
 for that.

 >
 > Broadly, "How, in general, should MacPorts approach this difference
 between the GNU and Darwin linkers?"
 No to seem glib, but we should patch when needed and report upstream when
 appropriate.

 > If building Boost (or any other library that exhibits such a pattern)
 with -flat_namespace would allow greater consistency,[[BR]]
 > I don't think that should be so quickly dismissed--'''especially in
 light of the guidance `pkg-config` users are getting regarding[[BR]]
 > `Requires.private`'''. This isn't just a Boost problem.[[BR]]
 > What's happening there could easily happen elsewhere.[[BR]]
 > 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.[[BR]]
 It seems to me that we don't have enough examples of things going wrong to
 form a good general strategy.

 > 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.[[BR]]
 > 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.
 I assume that Apple had good reasons for Two-level namespaces.[[BR]]
 I am not knowledgeable enough to advocate for them, but[[BR]]
 I would be wary of overriding this default linker behavior.

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


More information about the macports-tickets mailing list