From owner-freebsd-current Wed Feb 14 21: 3:55 2001 Delivered-To: freebsd-current@freebsd.org Received: from harmony.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id EF32F37B491 for ; Wed, 14 Feb 2001 21:03:51 -0800 (PST) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.11.1/8.11.1) with ESMTP id f1F53mW89652; Wed, 14 Feb 2001 22:03:48 -0700 (MST) (envelope-from imp@harmony.village.org) Message-Id: <200102150503.f1F53mW89652@harmony.village.org> To: "Danny J. Zerkel" Subject: Re: Major bumping of libFOO Cc: current@FreeBSD.ORG In-reply-to: Your message of "Wed, 14 Feb 2001 23:43:18 EST." <01021423431802.00537@zoomer> References: <01021423431802.00537@zoomer> <01021422425001.00537@zoomer> <200102150238.f1F2cBE75244@billy-club.village.org> <200102150400.f1F40QW89218@harmony.village.org> Date: Wed, 14 Feb 2001 22:03:48 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message