Any chance of getting this into stable? If not, could you add the getline sed to 0.9.28.3-r8 as well so it'll work with a stable glibc-2.10? Thanks.
uclibc-0.9.28.3-r8 is an easy stable (done), but i dont see a problem with doing 0.9.30.1-r1 too
looks like 0.9.30.1-r1 has issues with finite. upgrading my stable system resulted in: /usr/bin/python2.6: symbol 'finite': can't resolve symbol in lib '/usr/lib/libpython2.6.so.1.0'. and indeed, we see: $ readelf -s /lib/libm.so.0 | grep finite 16: 0000920d 18 FUNC GLOBAL DEFAULT 7 __finitef 26: 00009ceb 19 FUNC GLOBAL DEFAULT 7 __finitel 27: 00007c3c 31 FUNC GLOBAL DEFAULT 7 __finite while with 0.9.28.3 we see: $ readelf -s /lib/libm.so.0 | grep finite 22: 0000c618 24 FUNC GLOBAL DEFAULT 8 __finitef 31: 0000c658 44 FUNC GLOBAL DEFAULT 8 __finitel 32: 0000c630 40 FUNC GLOBAL DEFAULT 8 __finite 79: 0000c618 24 FUNC WEAK DEFAULT 8 finitef 90: 0000c658 44 FUNC WEAK DEFAULT 8 finitel 91: 0000a7fc 23 FUNC GLOBAL DEFAULT 8 finite so some config option will need tweaking before we can move to stable
SpanKY, took a quick look around for the issue you are having and it seems that finite has been removed(deprecated) from uClibc, the application (python I think from your post) needs to now use isfinite() macro instead of finite and be recompiled. See post http://lists.busybox.net/pipermail/uclibc-cvs/2009-February/026013.html
thanks for looking into that. a simple scanelf sanity check should be added then to uclibc's pkg_setup so we dont break people's systems.
hrm, similar problem with: __sysv_signal /usr/lib/libcrypto.so.0.9.8 getpt /usr/bin/screen these ones cant be fixed by re-emerging
Ok some more research for you ;) The following link mentions the sysv_signal requiring an option in the config which is also OBSOLETE... UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL, after building uClibc-0.9.30 and checking the config, mine was unset by default. http://ibot.rikers.org/%23uclibc/20081118.html.gz Extract.... 14:17.55 xming /usr/lib/libcrypto.so: undefined reference to `__sysv_signal' 14:18.45 blindvt` xming, just look for sysv_signal in extra/Configs/Config.in 14:19.07 xming ok, think I need to recompile my whole chroot 14:19.07 blindvt` xming, i attempted to document the symbols that are affected by the respective options 14:19.43 blindvt` config UCLIBC_HAS_OBSOLETE_SYSV_SIGNAL Setting the config option indicates the symbol is now provided. objdump -t uClibc/lib/libc.a | grep sysv 00000000 l df *ABS* 00000000 sysv_signal.c 00000000 g F .text 00000084 __sysv_signal 00000000 g F .text 00000084 sysv_signal The packages which break will still need to be fixed if that option disappears but it will allow it to go stable quicker???
UCLIBC_HAS_GETPT=y is required in the config to have the symbol getpt available. objdump -t ./lib/libc.a | grep getpt getpt.os: file format elf32-littlearm 00000000 l df *ABS* 00000000 getpt.c 00000020 g F .text 00000008 getpt The following thread makes reference to this issue. http://www.mail-archive.com/uclibc@uclibc.org/msg03277.html
the poll() fix will also need to be added before we can stabilize
Any progress here? Actual stable uclibc-0.9.28.3-r8 with stable linux-headers results in bug #253874. However the mentioned fix does not work for this version and it took me lots of efforts to go back to linux-headers-2.6.27-r2. If a newer version that already contains the fix is not ready yet to be stabilized, maybe block >=linux-headers-2.6.28 to prevent others hitting this?
(In reply to comment #9) > Any progress here? > Actual stable uclibc-0.9.28.3-r8 with stable linux-headers results in bug > #253874. > However the mentioned fix does not work for this version and it took me lots of > efforts to go back to linux-headers-2.6.27-r2. > > If a newer version that already contains the fix is not ready yet to be > stabilized, maybe block >=linux-headers-2.6.28 to prevent others hitting this? Actually, it turned out that the failure is not related to the fix proposed in bug #253874...
let's aim for 0.9.33.1
