uClibc-0.9.30.2 released - Looks like 0.9.30.3 may also follow along fairly soon to solve some issues on mips? Bumping the ebuild would be very helpful - I'm currently maintaining a big pile of patches of backports to 0.9.30.1 to build quite a bit of software ...Nice to see the uclibc guys continue to release!
0.9.30.3 was released on 2010-03-12.
0.9.31 was released April 2, 2010
I got a stage3 built using 0.9.31 by hacking up uclibc-0.9.30.1-r1.ebuild and playing with uclibc's .conf. Here's the ebuild diff diff -Naur uclibc-0.9.30.1-r1.ebuild uclibc-0.9.31.ebuild --- uclibc-0.9.30.1-r1.ebuild 2010-01-19 00:07:20 +0000 +++ uclibc-0.9.31.ebuild 2010-04-13 23:57:20 +0000 @@ -19,9 +19,9 @@ export CTARGET=${CHOST%%-*}-pc-linux-uclibc fi -MY_P=uClibc-0.9.30.1 +MY_P=uClibc-0.9.31 SVN_VER="" -PATCH_VER="1.0" +#PATCH_VER="1.0" DESCRIPTION="C library for developing embedded Linux systems" HOMEPAGE="http://www.uclibc.org/" SRC_URI="http://uclibc.org/downloads/${MY_P}.tar.bz2"
Created attachment 227695 [details] Working uclibc configuration file The default configuration file that comes with the uclibc tarball doesn't work in gentoo. You need to set a few things. See also https://bugs.busybox.net/show_bug.cgi?id=1543
Bump please. We we see this in the portage tree? (In reply to comment #4) > Created an attachment (id=227695) [details] > Working uclibc configuration file > > The default configuration file that comes with the uclibc tarball doesn't work > in gentoo. You need to set a few things. See also > > https://bugs.busybox.net/show_bug.cgi?id=1543 >
Tried playing with compiling this via cross-compiler for mips and it'll die on: >>> Install uclibc-0.9.31 into /usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image/ category sys-libs make -j3 DESTDIR=/usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image/ install HOSTCC extra/scripts/unifdef MKDIR /usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image//lib/ make: *** No rule to make target `/usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image//usr/lib/', needed by `install_dev'. Stop. make: *** Waiting for unfinished jobs.... MKDIR /usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image//usr/include emake failed * ERROR: sys-libs/uclibc-0.9.31 failed: * install failed Workaround available? Once I get this figured out, and can cross-compile to mips, I can look at fixing this bug.
Are there any updates?
*** Bug 352597 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > Tried playing with compiling this via cross-compiler for mips and it'll die on: > > /usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image//lib/ > make: *** No rule to make target > `/usr/mips-unknown-linux-uclibc/tmp/portage/sys-libs/uclibc-0.9.31/image//usr/lib/', > needed by `install_dev'. Stop. That surely is just a matter of the install scripts assuming the presence of the usr/ directory or some such? I'm yet to strike it here, I'm in the midst of building a µClibc environment here for mipsel. I haven't gotten to rebuilding µClibc itself. I'll give the ebuild patch in comment #3 a try and see how it goes.
Created attachment 265701 [details] Proposed ebuild
Okay, I get a different error: >>> Install uclibc-0.9.31 into /tmp/portage/sys-libs/uclibc-0.9.31/image/ category sys-libs make DESTDIR=/tmp/portage/sys-libs/uclibc-0.9.31/image/ install make[1]: `lib/ld-uClibc.so' is up to date. MKDIR /tmp/portage/sys-libs/uclibc-0.9.31/image//lib/ install -m 755 ./lib/lib*-0.9.31.so \ /tmp/portage/sys-libs/uclibc-0.9.31/image//lib/ (cd ./lib && tar -cf - *.so.*) | tar -xf - -C /tmp/portage/sys-libs/uclibc-0.9.31/image//lib/ tar: ld-uClibc.so.0: Cannot change mode to rwxrwxrwx: No such file or directory tar: Exiting with failure status due to previous errors make: *** [install_runtime] Error 2 emake failed
Created attachment 265707 [details, diff] Workaround/fix for bug in comment 11 Not sure whether this is the correct fix or not, but it's here for comment. Now for the problem in comment #6, which I am now able to reproduce.
Created attachment 265709 [details, diff] Workaround/fix for bug in comment 6 And it appears this fixes the problem in comment #6. It would appear that in the dependencies for the install_dev target, they call one of the installation directories $(PREFIX)$(DEVEL_PREFIX)$(MULTILIB_DIR). However, earlier in this, they call it $(PREFIX)$(DEVEL_PREFIX)/lib, which is slightly different. Probably the same path, but the strings are different, and that confuses make. I believe $(MULTILIB_DIR) is what was meant. Now it's just a matter of knowing if the Makefile.in is generated by the build system or not. If it is, we need to find the file that generates it, and patch it... otherwise my two patches should go upstream, and into the ebuild.
Created attachment 265713 [details, diff] Difference between my initial broken config, and one that works Well, building this broke Python in my chroot. Luckily, not the compiler though. As I began to recompile Python, I noticed a few warnings about threadding being disabled. That was a tip-off to re-visit my µClibc configuration. Looking at http://bugs.gentoo.org/attachment.cgi?id=227695 it is apparent that for whatever reason, threadding got disabled completely. On MIPS, the "new-style" linuxthreads is a non-starter, but the old one works. After hand-rebuilding µClibc, Python works again. We will need to pickle this change into the ebuild somehow.
(In reply to comment #14) > Created attachment 265713 [details, diff] > Difference between my initial broken config, and one that works > > Well, building this broke Python in my chroot. Luckily, not the compiler > though. As I began to recompile Python, I noticed a few warnings about > threadding being disabled. That was a tip-off to re-visit my µClibc > configuration. > How did it break? I'm asking because I'm running mips-uclibc on serveral boards with 0.9.30.1-r1 and want to upgrade. We should make the upgrade path smooth, although with uclibc's past history in this respect, I'm doubtful.
(In reply to comment #15) > > How did it break? I'm asking because I'm running mips-uclibc on serveral > boards with 0.9.30.1-r1 and want to upgrade. We should make the upgrade path > smooth, although with uclibc's past history in this respect, I'm doubtful. Python, which had been previously compiled against a thread-enabled µClibc segfaulted when it was compiled against a thread-disabled µClibc. If it didn't segfault, it died due to not finding libpthread.so.0. Either way, it broke. In both cases, I found the cause to be threading being disabled on µClibc, which explains the breakage in both cases.
(In reply to comment #16) > Python, which had been previously compiled against a thread-enabled µClibc > segfaulted when it was compiled against a thread-disabled µClibc. If it didn't ^^^^^^^^ Errm, executed, not compiled. > segfault, it died due to not finding libpthread.so.0.
I think you would be well worth your while going straight to uclibc-0.9.32 (ok RC for now) The new uclibc has working nptl threading for many architectures and so many improvements that I'm struggling to find some package which doesn't build against it (on x86 at least). Very cool The ebuild can be trivially bumped to point at an arbitrary git checkout by SRC_URI="http://git.uclibc.org/uClibc/snapshot/uClibc-7b74c6bab0fc39325a5b9a978a3d8ab73009e5d3.tar.bz2" and S=${WORKDIR}/uClibc-7b74c6bab0fc39325a5b9a978a3d8ab73009e5d3 (note the above are fairly old checkouts - review uclibc git and choose a checkout which looks suitable) Oh, and comment out "PATCH_VER" to prevent the ebuild trying to apply old patches.
0.9.32 final was released on 2011-06-08.
(In reply to comment #19) > 0.9.32 final was released on 2011-06-08. uclibc 0.9.32 fix issue with recent gnu AS : GEN include/bits/sysnum.h AS lib/crt1.o AS lib/Scrt1.o AS lib/crti.o AS lib/crtn.o /var/tmp/portage/cross-arm-guruplug-linux-uclibc/uclibc-0.9.30.1-r1/temp/ccatWA9a.s: Assembler messages: /var/tmp/portage/cross-arm-guruplug-linux-uclibc/uclibc-0.9.30.1-r1/temp/ccatWA9a.s: Error: .size expression for _init does not evaluate to a constant /var/tmp/portage/cross-arm-guruplug-linux-uclibc/uclibc-0.9.30.1-r1/temp/ccatWA9a.s: Error: .size expression for _fini does not evaluate to a constant make: *** [lib/crtn.o] Error 1 This is fix in uclibc commit 3e68c52b941636714d2599ea8adda9520ec2de23 http://git.uclibc.org/uClibc/commit/?id=3e68c52b941636714d2599ea8adda9520ec2de23
I have been using an ebuild that points at a specific git revisions for some while, working up to 0.9.32. I have to say that 0.9.32 is a fantastic improvement on many architectures and if you are bashing your head on some earlier version, just do yourself a favour and upgrade! I am happy to provide ebuilds, but we need some -embedded developer following this bug to help do something further Additionally, iconv support (and locale) seems to work ok with latest uclibc, although it does need some help if you are not building on glibc. If you are on uclibc, building for uclibc then try these instructions: http://lists.uclibc.org/pipermail/uclibc/2011-July/045494.html
Created attachment 282681 [details] sys-libs/uclibc-0.9.32.ebuild Here is a working uclibc ebuild for 0.9.32 This need a patch for sandbox otherwise make clean does clean files out of working dir
Created attachment 282683 [details, diff] files/uclibc-0.9.32-BJA-sandbox.diff This patch for not clean things out of working dir
Thanks Bertrand, but a note to those not using crossdev: This ebuild will die before it is done upgrading a local uclibc, leaving the system unusable. I'm glad I had a backup.
(In reply to comment #24) > Thanks Bertrand, but a note to those not using crossdev: This ebuild will die > before it is done upgrading a local uclibc, leaving the system unusable. I'm > glad I had a backup. Sheesh, nevermind, I just forgot to feed it a config :P
*** Bug 393223 has been marked as a duplicate of this bug. ***
(In reply to comment #23) > Created attachment 282683 [details, diff] [details, diff] > files/uclibc-0.9.32-BJA-sandbox.diff > > This patch for not clean things out of working dir I just added your ebuild and patch to the hardened-dev overlay in branch uclibc. I'll be testing this it with a hardened toolchain.
(In reply to comment #27) > (In reply to comment #23) > > Created attachment 282683 [details, diff] [details, diff] [details, diff] > > files/uclibc-0.9.32-BJA-sandbox.diff > > > > This patch for not clean things out of working dir > > I just added your ebuild and patch to the hardened-dev overlay in branch > uclibc. I'll be testing this it with a hardened toolchain. A little off the topic, but of interest to people following this bug: I've built two stage4 tarballs (stage3 + other stuff for a full development env). These are based on uclibc-0.9.32.1. Both are i386 but one is purely vanilla and the other has full toolchain hardening with both PIE and SSP. Now that uclibc supports nptl/tls its possible to do hardening in uclibc exactly as we do on glibc. The tarballs are at http://opensource.dyc.edu/pub/stage4-uclibc/ The overlay is at http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=shortlog;h=refs/heads/uclibc Note: my ebuilds are not for cross compiling. You should be able to propagate these stage4's by just updating them in place.
bump to 0.9.32.1, please. All older versions (including 0.9.32 without .1) do not build with binutils>2.21 (or >=2.21). Also, add uclibc-0.9.33_rc1 ebuild, please. Also, by the way, uclibc-0.9.32 and 0.9.33_rc1 don't build with crossdev for mipsel-linux-uclibc target (but it is okay under <target>-emerge with some enchancements like CROSS_COMPILE=mipsel-linux-uclibc- and UCLIBC_CPU="MIPS_ISA_MIPS32" in target's make.conf).
Created attachment 299519 [details, diff] Additional patch for crossdev build to work 0.9.32.1 with patch in attachment at least builds under crossdev.
Created attachment 299521 [details, diff] Diff from uclibc-0.9.32.ebuild to uclibc-0.9.32.1.ebuild Diff for ebuild from comment #22
Created attachment 303805 [details] uclibc-0.9.33.ebuild
Created attachment 303807 [details] uclibc-bom.patch
Created attachment 303809 [details] gen_wc8bit.patch
Created attachment 303811 [details] gen_wctype.patch
Please test the ebuild for uclibc-0.9.33 - seems like a good release to me To get full hardened support on at least x86/amd64 please add the following line to /etc/portage/env/sys-devel/gcc (or adjust the gcc-4.5.3-r2.ebuild) SSP_UCLIBC_STABLE="amd64 x86 mips" ...Then rebuild/upgrade to gcc-4.5.3-r2. This should give you an SSP/PIE capable compiler on uclibc Note there are some experimental patches in this ebuild - by all means comment them out, but grateful if folks could try them. The patches enable support for iconv and locale To adjust the locales built, please adjust the locales.txt file (see sample). At the moment it seems like you have to include locales in order to get iconv? It adds some 10s of KB to the library size if you include only a single locale To enable iconv/locale usage you will need a custom config file. See menuconfig and create your own. The locale ebuild stuff is these lines: # TODO: These should depend on some useflag, eg iconv # Run after make clean, otherwise files removed find ./extra/locale/charmaps -name "*.pairs" > extra/locale/codesets.txt #cp ./extra/locale/LOCALES ./extra/locale/locales.txt cp "${FILESDIR}"/locales.txt ./extra/locale/locales.txt # TODO: Now edit locales as appropriate... # FIXME: ... With a bit of tweaking this then seems to build quite a few additional packages. You no longer need libiconv to build iconv support into packages. Feedback appreciated - I listen in the gentoo-embedded forum also
Created attachment 303813 [details] locales.txt sample locales.txt - put in files dir and edit as appropriate
Created attachment 309039 [details] uclibc-0.9.33.1.ebuild Updated ebuild. Incorporates fledgling support for iconv and locales via use flag - however, you will need a manual config to actually enable support in uclibc also grab patches uclibc-bom, gen_wc*
(In reply to comment #38) > Created attachment 309039 [details] > uclibc-0.9.33.1.ebuild > > Updated ebuild. Incorporates fledgling support for iconv and locales via use > flag - however, you will need a manual config to actually enable support in > uclibc > > also grab patches uclibc-bom, gen_wc* I'm finding this approach to uclibc increasingly useless for what I do. I'm going to suggest an alternative approach which I have implemented on the hardened-dev overlay, uclibc branch. Here http://git.overlays.gentoo.org/gitweb/?p=proj/hardened-dev.git;a=blob;f=sys-libs/uclibc/uclibc-0.9.33.1.ebuild;h=751602844bcc63a59a0f21d85de1b0c355f25793;hb=6724d5302b3a9ba41d3b3c3734bc681e0a641e0e If this works for people I would be willing to ask the embedded folk if I can maintain uclibc ebuild and I'll make sure it stays up to day. Otherwise, I'm not that in whether the ebuild is in the tree or on my overlay.
> Otherwise, I'm not that in whether the ebuild is in the tree or on my > overlay. Oops! I'm not that *interested* in whether ...
I'm not sure what your point was? Do you mean that you just want to drop all the USE flags and ask users to create their own custom conf ? There seem to be two main things you are chucking out. One is the USE flags which mainly create a default conf file, but they have a minor advantage in pulling in some extra dependencies such as pax. The other is a bunch of stuff that I personally don't understand which seems to handle crosscompile My opinion is that whilst I personally only use custom config files, it does seem useful to keep the USE stuff in to help configure that since at worst it's just suboptimal, and at best it gives new users a useful leg up and helps narrow the range of bug reports from users significantly (seriously - otherwise there will be a mass of "why do I get missing prototype xxx") The crosscompile stuff I don't understand, but assuming someone does that seems like blackmagic that we either should throw out or get someone to claim and maintain? It's not a code path I'm using One way or another we desperately need this in mainline though. There are SO MANY bugs which are blocking on this getting in, and so many other devs are refusing sensible patches against a theoretical uclibc because it's not an ebuild which is in tree (which seems fair enough) If we can get *something* tested and into mainline, then nptl appears, most of the blockers disappears, iconv can be built, and almost every package in tree I have tried compiles fairly easily... Plus it's then fair game to file minor bugs against any problem packages because we actually HAVE a working uclibc So my vote is this needs to get into mainline, not just an overlay?
(In reply to comment #41) > I'm not sure what your point was? Do you mean that you just want to drop > all the USE flags and ask users to create their own custom conf ? > Yes. Otherwise they can fall back on the default which I've tested on the arches marked stable. > > The crosscompile stuff I don't understand, but assuming someone does that > seems like blackmagic that we either should throw out or get someone to > claim and maintain? It's not a code path I'm using I can put cross compile stuff back in my ebuild, but I want to avoid the numerous set_opt/get_opt based on use flags. I have never been able to use them and have always had to fall back on my own savedconfig. I understand what they're trying to do, eg USE=hardened, but like I said, I've always had to fall back on my own config. So, in my opinion: either use the tested default or know what you're doing and build your own config as users have to with the kernel. To be clear, I don't care what version is on the tree, I'm using mine. But if mine *were* on the tree, you can be sure it will be kept up to date.
Comment on attachment 265707 [details, diff] Workaround/fix for bug in comment 11 should be fixed via Bug 406335 (upstream commit 656167d89112171b2b7672676dc413)
Comment on attachment 265709 [details, diff] Workaround/fix for bug in comment 6 should be in 0.9.33 now (upstream e2903ddb06b1f50cb4ac9af0b035c74ed6b9d30f)
Comment on attachment 282683 [details, diff] files/uclibc-0.9.32-BJA-sandbox.diff this is in 0.9.33 now (upstream c61993f7e0ad3a9014a4b73823faf1ba914f48a0)
Comment on attachment 299519 [details, diff] Additional patch for crossdev build to work should be in 0.9.33 (upstream f1505e15812899623d77e40c62a4f66f57957e2d)
Anthony, I think we still have a few cases where we are going to back into using USE flags to amend the config. Consider hardened for example, and I'm also quite optimistic about iconv now. How do you propose we would handle these (or at least hardened/non hardened) going forward? Essentially we just need to be able to provide a default base config and then ideally flip things on for certain USE flags (surely someone will ask for something...?) I don't really care how we do this, I think we have to have some plan though?
(In reply to comment #42) for common settings, having USE flags in place makes sense. for more exotic stuff, we would push users to pick up custom configs rather adding more local USE flags. there might be room for trimming some stuff from the ebuild, but yours goes way too far. i can also see errors in there (like blindly clobbering /etc/TZ).
Comment on attachment 303807 [details] uclibc-bom.patch all of these random wchar/locale patches need documentation as to where they're coming from and what they're fixing further, if they're actual fixes, then we should be getting them upstream ...
They aren't all that random... Check the uclibc list - they are the last three patches I posted there... All been ignored so far though.. The BOM patch fixes an implementation bug in the iconv library and should definitely included upstream immediately. The other two patches fix the ability to build locales on a system which doesn't have a working locale itself. I don't build uclibc on glibc, so I can't check if it causes problems with that, so I would be grateful if others could test nothing breaks, however, I think the change is sound? Grateful if you could eyeball/test and if it seems ok I will resubmit perhaps a bit more forcefully upstream? Ta
the patches lack any metadata. that makes them random. please consult: http://dev.gentoo.org/~vapier/clean-patches i'd also highlight that one of them doesn't make much sense -- it modifies/adds code, but it's all commented out anyways. that makes it an in-development patch and not something that can be submitted.
They ARE in development. Please give feedback on the functionality.... Cleanup and repost is trivial if the effect is correct Ta
Hi Ed, I'm using your ebuild (or rather an ebuild based on yours), with the various patches included, and built a complete catalyst chain (stage1, stage2, stage3), so the locales are initially built within a uClibc system lacking proper locales support. Everything seems to work for the moment, except for gettext messages when using an UTF-8 locale. Here is an exemple of what I get : ginny ~ # LANG=fr_FR.UTF-8 rarp Invalid multibyte format string.Invalid multibyte format string.Invalid multibyte format string.Invalid multibyte format string. rarp -V affiche la version. Invalid multibyte format string.Invalid multibyte format string. strip (Metricom Starmode IP) ash (Ash) ether (Ethernet) tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25) netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet) dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi (HIPPI) irda (IrLAP) x25 (generic X.25) infiniband (InfiniBand) eui64 (Generic EUI-64) ginny ~ # LANG=fr_FR rarp Usage: rarp -a liste les entr�es en cache. rarp -d <hostname> supprime l'entr�e du cache. rarp [<HW>] -s <hostname> <adrmat> ajoute l'entr�e au cache. rarp -f ajoute les entr�es depuis /etc/ethers. rarp -V affiche la version. <HW>=Utilisez '-H <hw>' pour sp�cifier le type d'adresse mat�riel. D�faut: ether Liste les types de mat�riels supportant ARP: strip (Metricom Starmode IP) ash (Ash) ether (Ethernet) tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25) netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet) dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi (HIPPI) irda (IrLAP) x25 (generic X.25) infiniband (InfiniBand) eui64 (Generic EUI-64) ginny ~ # LANG= rarp Usage: rarp -a list entries in cache. rarp -d <hostname> delete entry from cache. rarp [<HW>] -s <hostname> <hwaddr> add entry to cache. rarp -f add entries from /etc/ethers. rarp -V display program version. <HW>=Use '-H <hw>' to specify hardware address type. Default: ether List of possible hardware types (which support ARP): strip (Metricom Starmode IP) ash (Ash) ether (Ethernet) tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25) netrom (AMPR NET/ROM) rose (AMPR ROSE) arcnet (ARCnet) dlci (Frame Relay DLCI) fddi (Fiber Distributed Data Interface) hippi (HIPPI) irda (IrLAP) x25 (generic X.25) infiniband (InfiniBand) eui64 (Generic EUI-64) I have those "Invalid multibyte format string" wherever a string is translated to a message containing non-ascii characters. I have verified that the *.mo files are identical between my glibc and my uclibc system.
(In reply to comment #52) my point is that these don't really belong in the ebuild (In reply to comment #53) unicode development really belongs on the uclibc list
i've taken Ed's ebuild, cleaned out some bits, fixed other parts, and committed it. it's running on my web server now. i'd like to kill off the CPU logic if possible. much of that upstream now just selects compiler flags.
(In reply to comment #55) > i've taken Ed's ebuild, cleaned out some bits, fixed other parts, and > committed it. it's running on my web server now. > > i'd like to kill off the CPU logic if possible. much of that upstream now > just selects compiler flags. Quick observation: hardened requires nptl for ssp.
(In reply to comment #56) i don't know what you mean ... nptl, ssp, and pie/relro (hardened) should all be orthogonal. if they aren't, then best to file a bug in upstream uclibc tracker.
(In reply to comment #57) > (In reply to comment #56) > > i don't know what you mean ... nptl, ssp, and pie/relro (hardened) should > all be orthogonal. if they aren't, then best to file a bug in upstream > uclibc tracker. They are in uclibc, but USE="hardened" => hardened toolchain and gcc requires nptl support to provide ssp.
you mean gcc's ssp implementation requires TLS support, and we have that (somewhat incorrectly) bound to USE=nptl in the toolchain.eclass
