[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