[[ 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.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to