From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Buck To: jat@traveller.com (John A. Tamplin) Cc: jbuck@synopsys.com, egcs@cygnus.com Subject: Re: Implications of tighter integration of libg++ Date: Tue, 10 Feb 1998 10:30:00 -0000 Message-id: <199802101727.JAA28815@atrus.synopsys.com> References: X-SW-Source: 1998-02/msg00439.html [ changes in libstdc++ interface ] > > Even so, perhaps a backward compatibility layer could be written. But it > > might be easier just to ship two libstdc++ versions with different major > > version numbers than to try to figure out how to make one library do. > Why couldn't you just have the compatibility layer in a separate library? Well, that's what two libraries give you. Ah, but you want a small compatibility layer rather than an entirely separate library. This is possible, but in the absence of a volunteer to do the job it isn't going to happen. > That way those symbols would only be used if it were explicitly added to > the link command. Doesn't work. Either you have source or you have an executable. If the executable uses the old interface and is dynamically linked, there is no link command, only ldd. The only control you have is LD_LIBRARY_PATH or equivalent. (OK, you might also have an old library, and there you could use a link command). > For those sites that didn't care about using the > previously reserved symbols, it could be automatically linked or even be > included as a separate object in the standard library. We can't put the old interfaces in the standard library. If we get to the point that g++ is essentially standard-conforming, it would be a disaster to then completely break standards conformance for the sake of g++-2.7.x or even g++-2.8.x compatibility. If a means were provided, it would have to be done in a way that extra action is required to get the compatibility stuff -- explicitly point to an old library or a compatibility library.