New version of uclibc is available. Several bugs have been closed due to fixes are available in upstream uclibc-0.9.29 but gentoo still has 0.9.28. There is for example no working version for xfsprogs for uclibc at this moment due to this.
Created attachment 122131 [details] uclibc-0.9.29.ebuild I created a set_opt func to set config options since the previous echo "KEY=y" >> .config didn't work.
FYI: the testsuite fails on hardened with a segfault. stack overflow in inet_network() or something like that? nc inet # make TEST_LINK inet/ bug-if1 TEST_LINK inet/ if_nameindex TEST_LINK inet/ tst-aton TEST_LINK inet/ tst-network TEST_LINK inet/ tst-ntoa TEST_LINK inet/ bug-if1_glibc TEST_LINK inet/ if_nameindex_glibc TEST_LINK inet/ tst-aton_glibc TEST_LINK inet/ tst-network_glibc TEST_LINK inet/ tst-ntoa_glibc TEST_EXEC inet/ bug-if1 TEST_EXEC inet/ if_nameindex TEST_EXEC inet/ tst-aton TEST_EXEC inet/ tst-network /bin/sh: line 1: 13173 Segmentation fault ./tst-network >&"tst-network.out" ret == 139 ; expected_ret == 0 Testing: 1.0.0.0 Testing: 1.0.0 Testing: 1.0 Testing: 1 Testing: 192.168.0.0 Testing: 141.30.225.2800 Test failed for inet_network ("141.30.225.2800"): Expected return value 4294967295 (0xffffffff) but got 2367611376 (0x8d1ee1f0). Testing: 141.76.1.1.1 make: *** [tst-network.exe] Error 1 nc inet # vim tst-network.c
Created attachment 122218 [details, diff] files/uclibc-0.9.29-inet_network.patch fixes a off-by-one bug in inet_network() that caused the FEATURES="test" to segfault. Reported upstream on the uclibc list.
Created attachment 122220 [details] uclibc-0.9.29.ebuild updated ebuild.
Hi folks, i bumped this ebuild myself and found out, that =sys-apps/net-tools-1.60-r13 doesn't compile with this version. Well, it's well explained here and you can also find a PROPOSED patch here -> http://lkml.org/lkml/2004/10/19/276 After using the patched uclibc-headers net-tools can be build again. Check the attached patch (files/uclibc-0.9.29-net-tools_compile.patch) please ;)
Created attachment 123102 [details, diff] files/uclibc-0.9.29-net-tools_compile.patch files/uclibc-0.9.29-net-tools_compile.patch
Would it be an idea to add the ebuild to the portage tree, maybe even masked? It would be easier to fix things if there are specific bugs to fix.
Its need adapted patches from prev ebuild for C99 math.h ...
(In reply to comment #8) > Its need adapted patches from prev ebuild for C99 math.h ... > Why were those not included in upstream 0.9.29?
Upstream claims that "Currently uClibc runs on alpha, amd64, ARM, Blackfin, cris, h8300, hppa, i386, i960, ia64, m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.", while Gentoo has KEYWORDS="-* ~arm ~m68k -mips ~ppc ~sh ~sparc ~x86" (i.e. amd64 is missing).
i'm fully aware of what upstream claims (especially considering i added a couple of those arches), but it doesnt mean it's ready for them in Gentoo i didnt port uClibc to amd64 until after 0.9.28 and not all of the ones listed support ldso (which means there's no point in doing Gentoo on them yet)
i am looking into getting the c99 math funcs included upstream. If they get included I will try make a backport patch for 0.9.29.
Do we need all the c99 math funcs or should we just cherrypick the most needed ones? I cant find any code (google code search) that uses log2() for example.
we only add ones as needed
(In reply to comment #8) > Its need adapted patches from prev ebuild for C99 math.h ... > which package need what c99 func?
(In reply to comment #15) > which package need what c99 func? It's WAS needed by uclibc++ which compiling with float and long math functions by default... But I disabled it in ebuild and problem was gone... So C99 math is not so hardly needed...
(In reply to comment #16) > (In reply to comment #15) > > which package need what c99 func? > > It's WAS needed by uclibc++ which compiling with float and long math functions > by default... But I disabled it in ebuild and problem was gone... > > So C99 math is not so hardly needed... cool. so then i can collect a set of patches (from buildroot and other projects) and we might be able to add 0.9.29 to the portage tree. we can add math functions as needed later.
(In reply to comment #4) > Created an attachment (id=122220) [edit] > uclibc-0.9.29.ebuild > > updated ebuild. > I tried to use crossdev with this ebuild to get a mipsel-linux-uclibc toolchain. But it always tries to compile i386 target for me. Strange. Previous ones like 0.9.28 and 0.9.27 worked as expected.
Created attachment 139367 [details, diff] uclibc-0.9.29.ebuild.diff This diff against latest portage uclibc, apply most of attachment#122220 [details]. Fixes cross compile, endian, host cc, includes and more. Checked for i586, mipsel... Bad luck with mipsel... dso causes floating point exception... Strange... Anyway, result is a better shape ebuild. vapier, I will be glad to receive comments regarding this one... :)
Option UCLIBC_HAS_GU_GLOB is need to be enabled for some packages...
I'm currently testing uclibc 0.9.29 with the files presented here (ebuild diff and two patches). I can confirm the comment about the UCLIBC_HAS_GNU_GLOB option. In particular, make fails to build without it here. In particular, I'm trying to enable the iconv use flag (which enables all kinds of locale support in uclibc). However, I found that using iconv without setting the pregen useflag breaks compilation. It seems this combination would try to generate the locale data at compile time. From the uclibc documentation, I found that this is completely not supported. In particular, the "make locale_headers" errors out. It uses (through some -D option) $(top_build_dir) (which is set to './') in an #include statement in a file that is not at the root (ie, extra/locales/gen_wc8bit.c does #include ./include/something.h, which should be ../../include/something.h or something with -I's or I don't know what). Perhaps having iconv but not pregen should generate a warning? Additionally, it seems that setting the nls use flag has no effect when iconv is not set. Should that be noted somewhere? Lastly, I'm having some trouble getting the pregen option to work properly, but I'll come back to that.
Created attachment 144018 [details, diff] Updated diff I'm embedding gentoo on a PXA270, but to optimize I needed to modify the latest patch to 0.9.29 to support IWMMXT on bintuils-2.18.50.x/gcc-4.2.3. To do so in a generic way this patch adds two optional command line variables: UCLIBC_CONFIGURATION which allows modification of the .config file (in my case to turn off OABI and on EABI); and UCLIBC_EXTRA_CFLAGS which allows modification of the compiler (in my case setting -mcpu=iwmmxt -mabi=aapcs-linux -mfloat-abi=soft -mfpu=vfp etc.). Other than that the patch is very similar (diff'ed against 0.9.28.3-r2). On a side note, in order to get gcc to stage2 rebuild (including C++ support) uclibc_nonshared for some reason builds aeabi_lcsts with an unknown architecture, necessitating passing to gcc a -Wl,--accept-unknown-input-arch for the time being. Have yet to discover why though, as it appears to compile / link in much the same way as the rest of the library.
I believe I have found the minor mistake in the side note for aeabi_lcsts as RESTRICT was still using "nostrip" in my test ebuild (which would then run i686-pc-linux-gnu-strip, strangely enough succeeding on the arm libraries but removing the architecture info for just the first object).
Created attachment 148873 [details] Complete ebuild based on patch by Paul Davis (In reply to comment #22) > Created an attachment (id=144018) [edit] > Updated diff > Thanks to an update in the 0.9.28-r2 ebuild by Phreak, the patch no longer works on that ebuild. After patching it by hand, I recreated the new one based on the patch by Paul Davis on 19 Feb 2008.
uclibc 0.9.29 is over a year out. why is this not in portage tree? what is the problem with this ebuild? I think with this we would have lesser problems than with .28
(In reply to comment #25) > uclibc 0.9.29 is over a year out. why is this not in portage tree? what is the > problem with this ebuild? I think with this we would have lesser problems than > with .28 > Don't assume simply cuz the number is bigger that it is better. 0.9.29 has stdio problems. If 0.9.29 is ever added to the tree it will be done so by the bug reporter who is on the track of becoming a dev.
(In reply to comment #26) > 0.9.29 has stdio problems. Like? References, URLs, ML posts would help..?
(In reply to comment #26) > (In reply to comment #25) > > uclibc 0.9.29 is over a year out. why is this not in portage tree? what is the > > problem with this ebuild? I think with this we would have lesser problems than > > with .28 > > > > Don't assume simply cuz the number is bigger that it is better. 0.9.29 has > stdio > problems. If 0.9.29 is ever added to the tree it will be done so by the bug > reporter who is on the track of becoming a dev. > https://dev.openwrt.org/cgi-bin/trac.fcgi/browser/trunk/toolchain/uClibc/patches/0.9.28.2 Could we then please get some patches in to fix the current version?
uClibc-0.9.30 in portage now, so this request need to be renamed or droped?
Please file a new bug for the new release if needed. Also due to limited manpower it's much better to try to push any patches upstream for .31
