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