| Summary: | stabilize sys-libs/uclibc-0.9.30.1-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ryan Hill (RETIRED) <rhill> |
| Component: | New packages | Assignee: | Embedded Gentoo Team <embedded> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | enhancement | CC: | DuPol |
| Priority: | High | Keywords: | STABLEREQ |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ryan Hill (RETIRED)
2009-10-17 20:56:02 UTC
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 |