This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
>>>>> Ulrich Drepper writes: Ulrich> Andreas Jaeger <aj@suse.de> writes: >> I checked now [1] the *map files for 2.1.3 and 2.2 and noticed a >> problem with __libc_freeres, it got the wrong version number in >> 2.1.3. I'm appending a patch to synch this with glibc 2.2. Ulrich> I applied the second part. But the __libc_freeres change is not OK. Ulrich> 2.1.3 was the first release where the function was exported. Ulrich> Therefore the version name has to be GLIBC_2.1.3. This is not Ulrich> versioning is for since now GLIBC_2.1.3 is used as the most recent Ulrich> versions in all binaries which use __libc_freeres and ld.so will Ulrich> immediately stop if you run this program with a libc before 2.1.3. The problem is malloc/Versions in glibc 2.1.3, it contains a GLIBC_2.1 instead of GLIBC_2.1.3: GLIBC_2.1 { # Special functions. __libc_freeres; } glibc 2.1.3 has therefore: $ readelf -a /lib/libc.so.6 |grep __libc_freeres 000dc0a0 40c07 R_386_JUMP_SLOT 00054524 __libc_freeres 000c4a48 40c01 R_386_32 00054524 __libc_freeres 1036: 54524 81 FUNC GLOBAL 0 16 __libc_freeres@@GLIBC_2.1 5276: 54524 81 FUNC GLOBAL 0 16 __libc_freeres The bug is in glibc 2.1.3 - and for compatibility we should use the same version number. Are you sure this will work now? AFAIK a program linked against glibc 2.1.3 using __libc_freeres will fail with glibc 2.2 since the versions don't match. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.rhein-neckar.de
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |