Cristian Gafton wrote: > > On Fri, 26 Mar 1999, Burchard Steinbild wrote: > > > In a discussion we had the following question: > > > > > What will the naming convention be for /usr/lib/*std* > > > In other words these: > > > /usr/lib/libstdc++.so.2.9 > > > /usr/lib/libstdc++.so.2.9.0 > > > With this naming convention you can't tell if the lib was created on > > > a libc5, glibc2.0, or glibc2.1 machine... > > > > this is not fully correct. At least it's no problem to decide if a lib > > was build with libc5 or glibc. > > Yes, there are problems for applications that were compiled with the > broken RPATH set (don't ask why people would do this, but they are doing > it). Also, a lot of the versions that float around for > libstdc++ were not linked against the C library (using -lc) and those libs > will be "good to go" for any program that requires it, regardless of > libc5/glibc issues. > > > I'm not sure, but would it also be > > possible, to change ldso that way, that it can make a difference between > > glibc2.0 and glibc2.1 libraries (maybe with the assumption "no versioning" > > -> "2.0"). > > The problem with this is that a potential mix of glibc 2.0 and glibc 2.1 > libraries is fatal. For example if you decide to load glibc 2.0 for a > program based on the lack of versioning, that program might require > another library for which you don't have a glibc 2.0 version, so the > loader will have to proceed and load the glibc 2.1 one, which in turn will > load glibc 2.1, so you will end up with glibc 2.0 and glibc 2.1 loaded at > the same time for a program. > > > > Redhat's next release (glibc 2.1 base) has a new naming convention which > > > incorporates the glibc version into the name...ie: > > > > > > /usr/lib/libstdc++-2-libc6.1-1-2.9.0.a > > > /usr/lib/libstdc++-libc6.1-1.a.2 -> libstdc++-2-libc6.1-1-2.9.0.a > > > > On our meeting we agreed not to worry too much about backward > > compatibility due to glibc versions. But imho this has to be covered > > in LSB anyway. > > The general idea is that we are using in our egcs compiler the Linux patch > put together by H. J. Lu. That includes this "hack" with which I happen to > agree because of the multiple failure scenarios. > > > Please Christian, give me another chance and explain me, why this ugly > > names in your opinion are a MUST. Thanks. > > I don;t think that the names matter that much - it's just a soname and the > system takes care of it, ugly or not. The problem we are trying to solve > here is caused by the fact that libstdc++ is a very special library and > libstdc++ compiled against glibc 2.0 is not compatible with the one > compiled against glibc 2.1. So if a vendor compiles an app on glibc 2.0 > and it is using that system's libstdc++ the respective app will not run on > a glibc 2.1 system if the glibc 2.1 system does not change the soname of > the libstdc++ library and provides the old one as a backward > compatibility. In short, why ? An example for the uninitiated ... wasn't the .x.y extension of sonames supposed to help ?
More questions: - how do I produce a .so which exhibits the problem ? - how do I produce a .so which avoids the problem (while still using glibc) ? - what makes libdstdc++ special ? > And this is only a part of the problem, you also have gcc/egcs issues > (both ship libstdc++.so.9) and guess what - they are incompatible. > > So the issues imho is not if changing the name so we will stop using > libstdc++.so.9 no matter of the compiler/library combination - we can > argue about the form of the new soname, making the names less "ugly", etc. > > But IMHO is better to tell the vendors that one libstdc++ might not be > compatible with another one on another system than to keep their hopes > high and then make them spend time debugging stuff to discover what we > already know about the incompatibilities. Are details about glibc, libdstdc++ and incompatibilities thereof available somewhere on the Internet, possibly with examples ? > And the patch we use by no means is RH specific or anything - it is a > patch put out by H. J. Lu, and it just so happens that I trust that patch > because so far it is the only solution that I know of that will make egcs > give reproducible results. > > Best wishes, > > Cristian > -- > ---------------------------------------------------------------------- > Cristian Gafton -- [EMAIL PROTECTED] -- Red Hat Software, Inc. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > UNIX is user friendly. It's just selective about who its friends are. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with subject of "unsubscribe". Trouble? Email [EMAIL PROTECTED] Davide Bolcioni -- #include <disclaimer.h> // Standard disclaimer applies
