David,
I noticed that MacPorts was using the llvm.org 3.4.1 headers with the
system libc++ shared library and filed a bug report on that…
https://trac.macports.org/ticket/43828
The response off list was as follows…
> Have you ran this pass the Apple clang and libc++ programmers?
Yes. You can probably search macports-dev mailing list history as well to
see where we discussed this in the past. This was done specifically
because we discussed it in house and decided that this was the best
approach. I suggest that you do the same on fink.
> I have never heard of mismatching headers and shared libraries as being
an acceptable design decision.
It usually isn't, but the host C++ runtime needs to be binary compatible
across releases, and you can not share objects between different runtimes
in the same process.
> In fink, we default to both the system c++/v1 headers and the system
libc++ shared library.
That's safe as well, but then you don't get the improvements of the newer
STL.
> If the packager or user wants to use the libc++ from llvm.org's 3.4.1
release, they are told to use -cxx-isystem %p/include/c++/v1 -L%p/lib/c++
to access them.
Have fun dealing with all the users who shoot themselves in the foot
following your instructions.
and
> While I think the inverse would be safe, i.e. using the older system
libc++ headers with the newer libc++ shared libraries (as long as there
hasn't been an so version bump), I don't see how the mixing of newer
headers with older shared libraries can possibly be safe as the newer
header may well define new calls, etc not present in the older shared
library.
Yes, and if that's the case (which isn't actually quite frequent), the user
will get an error at link time that will be obvious. As solution, they can
either install a newer C++ runtime than is provided by their host OS or
upgrade to a newer host OS with a newer C++ runtime.
With your fink case, users will get successful linking, and things will
fall apart at runtime as different libraries try to share objects across
C++ runtimes.
I haven't found the macports-dev thread that Jeremy mentioned but according
to him we should actually default clang34 to use the libcxx1-dev headers by
default. That could be trivially done by changing the paths in the
PatchScript sed statements that I added in -0d/0e. MacPorts automatically
picks up the headers due to their relative location to the compiler.
Jack
------------------------------------------------------------------------------
The best possible search technologies are now affordable for all companies.
Download your FREE open source Enterprise Search Engine today!
Our experts will assist you in its installation for $59/mo, no commitment.
Test it for FREE on our Cloud platform anytime!
http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
