Borland's pre-install script for Kylix tests for a libc bug that it claims exists in Potato. I've included the output of its test script below.
Does anyone know of a workaround/bugfix? I searched but didn't find anything about this. Presumably it's fixed on Woody/Sid, but I didn't test it there. Thanks, -- Pete Harlan [EMAIL PROTECTED] > Borland Kylix System Compatibility Test > > Checking loader....This will test whether libc installed on your system has > a design flaw of the dynamic loading of > shared objects. By dynamicly loading shared object 'a' that depends > on shared objects 'b' and 'c', then dynamically loading shared object 'b' > which depends on 'c', shared object 'c' will remain in memory when 'a' > and 'b' are closed. > > This is what is in memory now: > Name Address Handle > ------------------------------------------------------------------- > 0x00000000 0x400136f0 > /lib/libdl.so.2 0x40019000 0x40013c60 > /lib/libc.so.6 0x4001e000 0x4001d000 > /lib/ld-linux.so.2 0x40000000 0x40013420 > Loading shared object lib-a.so > And this is what is now in memory > Name Address Handle > ------------------------------------------------------------------- > 0x00000000 0x400136f0 > /lib/libdl.so.2 0x40019000 0x40013c60 > /lib/libc.so.6 0x4001e000 0x4001d000 > /lib/ld-linux.so.2 0x40000000 0x40013420 > /var/home/erik/tmp/borpretest/lib-a.so 0x40015000 0x0804af80 > /var/home/erik/tmp/borpretest/lib-b.so 0x40017000 0x0804b228 > /var/home/erik/tmp/borpretest/lib-c.so 0x400fb000 0x0804b4d0 > Getting address of 'a_function' and calling it > Now loading shared object lib-b.so > Again, this is what is in memory > Name Address Handle > ------------------------------------------------------------------- > 0x00000000 0x400136f0 > /lib/libdl.so.2 0x40019000 0x40013c60 > /lib/libc.so.6 0x4001e000 0x4001d000 > /lib/ld-linux.so.2 0x40000000 0x40013420 > /var/home/erik/tmp/borpretest/lib-a.so 0x40015000 0x0804af80 > /var/home/erik/tmp/borpretest/lib-b.so 0x40017000 0x0804b228 > /var/home/erik/tmp/borpretest/lib-c.so 0x400fb000 0x0804b4d0 > Getting address of 'b_function' and calling it > Now this is where things begin to break down. The lib-b.so handle > will be closed first, then the lib-a.so handle will be closed. Expected > behaviour should be that the objects in memory return to the state prior > loading lib-a.so > Closing b_handle > Name Address Handle > ------------------------------------------------------------------- > 0x00000000 0x400136f0 > /lib/libdl.so.2 0x40019000 0x40013c60 > /lib/libc.so.6 0x4001e000 0x4001d000 > /lib/ld-linux.so.2 0x40000000 0x40013420 > /var/home/erik/tmp/borpretest/lib-a.so 0x40015000 0x0804af80 > /var/home/erik/tmp/borpretest/lib-b.so 0x40017000 0x0804b228 > /var/home/erik/tmp/borpretest/lib-c.so 0x400fb000 0x0804b4d0 > So far so good > Closing a_handle > Name Address Handle > ------------------------------------------------------------------- > 0x00000000 0x400136f0 > /lib/libdl.so.2 0x40019000 0x40013c60 > /lib/libc.so.6 0x4001e000 0x4001d000 > /lib/ld-linux.so.2 0x40000000 0x40013420 > /var/home/erik/tmp/borpretest/lib-c.so 0x400fb000 0x0804b4d0 > WHOOPS!!! Lookie there! lib-c.so is still hanging around! This is bad... > Thanks for your time > FAILED > Checking kernel >= 2.2....OK > Checking libc >= 2.1.2....Major version is 2 > Minor version is 1 > Revision version is 3 > OK > Checking libjpeg >= 6.2.0....Checking /usr/lib/libjpeg.so.62 > /usr/lib/libjpeg.so.62 resolves to libjpeg.so.62.0.0 > Checking /usr/lib/libjpeg.so.62.0.0 > Major version is 62 > Minor version is 0 > Revision version is 0 > OK > > This system is not compatible with Borland Kylix. Please see the > documents in this directory for information on how to upgrade your > system. >
