[[ see end of message for major downer ]]
In message <01021423431802.00537@zoomer> "Danny J. Zerkel" writes:
: These lines come from Makefile.in in the vendor's source.
So are you saying it should be 3.1 instead so that the vendor can come
out with 4 later? It must be different than 3.
: But, not so hard to link against a particular interface. Now, of course,
: if they look for a particular interface number that we don't support, it
: has to come from somewhere (or someport) else.
Who does that? I'm sorry, but libstd++.so.2 won't work with anything
but old versions of the system. Any body that tires to link against a
specific version of a shared library is broken. Can you point at any
port in the tree that does this? Any makefile? I don't think any
such exist. Therefore the major number doesn't matter.
Also, the mere fact tht INTERFACE is currently 3 and SHMAJOR is
currently 3 is a coincidence.
If there were two different interfaces that we were trying to support,
we'd have libstdc++2 and libstdc++3 shared libraries.
: Well, I'm not arguing against fixing things, to be sure. I'm just wondering
: to what extent the major numbers for vendor libraries are ours.
If the library is in the base system, we have 100% control over the
major number. At least that's my position and one I've seen extolled
in the past.
: At very
: least, I think I would like to see obrien sign off on the plan. Naturally,
: it won't matter for vendor libraries that don't build shared versions, but
: we do. But, at least for libstdc++, it is a vendor shared library. We
: should consider the ramifications.
Yes, that's why we're changing the major number. I'd like to see
David sign off on it as well (and will send him mail if I don't hear
from him tonight). The version number must change because it is no
longer compatible with the old libstd++.so.3. It can change to 4, or
3.1 or pink. It doesn't matter to me.
: The reason I'm bringing it up is, 1) to make sure it is considered. 2)
: because it IS in the base system. There appear to be ports linked against
: non-latest versions of other ports libraries. It would be much harder to
: do that against vendor libraries in the base system if the version number
: jumps around. Of course, this may be no concern at all. But, from the
: phrasing of your answer, I think that at least it was worth mentioning.
The fact that the ports are currently linked against libstdc++ is
irrelevant. Unless the ports in question specifically link against
-lstdc++.3, I don't see what the problem is.
However, This does bring up an interesting point. One I'm sure that
no one wants to hear.
I also think we have to do the same thing to all the ports. None of
them (well, most, the ones that use std{in,out,err}) are compatible
with the new libc, so the first port that you try to build that uses
one of these libraries will fail to build.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
