This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: versioning C++ includes


Nathan Myers <ncm-nospam@cantrip.org> writes:

[...]

| We can solve it by making a directory where our .so files go,

We already do this, along with smybol versioning.

|  and
| inviting builders of C++ libraries that depend on our .so files
| to put their libraries there too. 

This is out of our control because distributors put their libraries in
particular places specified at configure time, that aren't necessarily
writable by developpers.  At any rate, it isn't something in the scope
of V3.  We can publish some guidance about our ABI (that is what
Benjamin plans to do) but that is all about it.

Please also note that Benjamin's patch is out *headers* not built
binaries.  The binaries installation bits were handled in previous
patches. 

| Then we just have to arrange
| for our binaries to look there.  If we wanted to be thorough, we
| might --rpath the "gcc-$abi_version" subdirectory of each directory
| mentioned in a -L option.

Th --rpath thingy is problematic as was repeatedly pointed out.
At any rate, I think you're confusing the concrete and urgent problems
we're trying to solve here.

| C++ library package maintainers will still have to label (in the
| name or in the version) which compiler version was used to build
| their package, but those packages may then co-exist on the same 
| machine, and satisfy dependencies for programs built from anywhere.

The V3 library binaries can already coexist with  others.  It is the
problem of headers we're solving.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]