uclibc ebuild currently has no support for gcc-config. Tnis ebuild adds support for this. Other improvements are: installed more documentation and used mirror://kernel for the source url. works for ebuilds syslinux-2.06, sysvinit-2.83-r1 and undoubtly a few others. Fails for a lot as well. I will continue to work on this time permitting and just wanted to place this in as a placeholder. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 18110 [details] modified ebuild This probably works for version uclibc-0.9.21 as well. Currently compilation is very slow due to the number of wrappers around gcc. Still investigating solutions.
Created attachment 18116 [details, diff] diff of ebuild uclib 0.9.20
When attaching diff/patches's please make then unified context aware diffs using diff -u
Created attachment 18149 [details, diff] diff -u of ebuild uclib 0.9.20 Sorry mate - here's the diff -u.
Daniel First thank you for attaching a unified context. SpanKY has offered to take on support for this which I feel is great and will attempt to fully support by backing him up in which ever ways I can. One thing I like to point out or get an explanation from you Daniel on is I see ~ppc is listed in the $KEYWORDS but yet the attachment explictily only lists 'i386' in the PATH and so on, is there any reason for limiting this to only i386 or is this a limitation of uclibc? ----------------- SpanKY when you take this bug on please roll these patches for the current uclibc-0.9.21 which fixes a great number of outstanding bugs for uclibc that Erik Anderson, Glenn McGrath and other have worked so hard to fix. Note also offtopic.. do you want to handle busybox-1.00-preX or shall I?
solar - inclusion of ~ppc was a bit of an oversight. My understanding is the way the original ebuild, on which this was based, was made was explicitly for x86 only (CONFIG_GENERIC_386=y in the workdir .config file after the unpack). There is a longer method involving toolchaining from the uclib cvs that will support crossplatform (or so it says and I believe them). I'm considering doing either a cvs ebuild or a snapshot look at the cvs makefile for the toolchain documented on the uclibc site. This will involve the moderate use of sed as it expects to download other source code like binutils (and others that escape me now) but its not impossible. I saw somewhere in another bug there was some work on toolchaining by SpanKY (or yourself?). When/if I got around to producing a toolchain version I was going to attempt to base it on the other work. But for now this is a simple version that hopefully is of use. I saw a note by Eric that uclibc isn't going to guarantee binary compatibilty until version 1. This may also have some implications. Also offtopic note: I attempted to compile busybox with the gcc-config pointing to uclibc and it failed badly. I see it have a uclibc use flag though. My vision was with this ebuild to eliminate compiler select with useflags maybe. If you want to just pass some general guidance as to the future direction this ebuild shoud take I will attempt to implement it. BTW another trap I found is that optimising this ebuild to anything above 586MMX will break it. (documented obsecurely in their mailing lists)
i add the ppc because i used uclibc on my ppc ;) ... but i will look at the i386 define to make sure it isnt set ... as for binary incompatibility, thats not our problem, thats the users :)
I don't think we can escape the uclibc all together anytime soon in use flags. Many existing packages will need to have there own patches added to take proper advantage. Some packages can only be triggered by various environmental variables such as CROSS,CROSS_COMPILER_PREFIX,AR,RANDLIB,STRIP,LD all set correctly when compiling from anything other than a system thats already built as an i386 system. Rob McMullen has a helpful page uClibc with Gentoo Linux at http://www.geocities.com/robm351/uclibc/ I found Tavis Ormandy analyse-x86.sh http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=%22script+test+instruction+set%22&q=b and this rewrite in perl http://marc.theaimsgroup.com/?l=gentoo-dev&m=106071268500309&w=2 to be most helpful in the testing the end results of uclibc compiled binaries and libraries. As for direction I would hope to see a submissions of a uclibc compatible profiles added to gentoo for embedded/micro/small systems.
OK I'm working on a uclibc toolchain/crosscompiler (the above is a wrapper). If someone could give me a hint how to extract architecure from the -march= directive in the CFLAGS I'd appreciate it otherwise I will work it out (sed/perl/awk aren't my strong points). Thanks for the references solar ;-). There after I guess it will be time to merge the patches in http://www.geocities.com/robm351/uclibc/ into ebuilds with a USE flag for uclib. I see your point solar that we can't totally escape the use flags.
example in bash. CROSSARCH=$(for flag in ${CFLAGS}; do [ "${flag:1:5}" = "march" ] && echo ${flag:7}; done)
you could review flag-o-matic.eclass also, i think theres work with the variable CROSSHOST ... lisa and azarah would know for sure ...
hello. NB : I don't know if it's the right place to post,but this is the only bugs about uclibc. since uclibc is not able to fully replace glibc, I think that having a uclibc USE flag could be a nice way to do things. I made some tests , if the software can compile against uclibc without code modification it's quite simple. I used 2 ways to get the package compiling : a)modifying uclibc's ebuild to symlink files in /usr/i386-linux-uclibc/bin/ to remove the 'i386-uclibc-' part( so the wrapper is called gcc for exemple ). then in the software's ebuild , in section src_compile add : use uclibc && export PATH=/usr/i386-linux-uclibc/bin/:$PATH b)in the software's ebuild,in section src_compile add : use uclibc && $CC=/usr/i386-linux-uclibc/bin/i386-uclibc-gcc of course, if the software need special options for configure orso , it can also be putted there. I just tested some ebuilds so I don t know if it's the right way yo do things.I'm going to look it deeply.
Have you built the attached ebuild? There is basic gcc-config support so that a command "gcc-config i386-linux-uclibc-0.9.20" alters the /usr/bin/gcc (gcc-config wrapper) to point to the i386-uclibc-gcc (which is another wrapper that point the the real gcc after redirecting references to uclibc). A "use uclibc && gcc-config i386-linux-uclibc-0.9.20" will have the same effect as your b) suggestion below. Except of cause it is version dependant that much is flawed. Other enviroment variables such as those solar mentioned in comment 8 also need to be modified to ensure correct complilation against the right libraries. Solar's reference above are a good start for learning. I am still making an ebuild that produces a toolchain (native) compiler rather than the current wrapper implementation. Hopefully it will work as I've described above. It may be possible as I've tested with sysvinit to just on the commandline enter the gcc-config command followed by ebuild package with no modification of the ebuild. Question for the developers here while I'm at it. The below code fragment is from my currently re-(e)build. Is this flawed too much? GCCVER=$(${CC} -dumpversion) SRC_URI="mirror://gnu/gcc/releases/gcc/gcc-${GCCVER}/gcc-${GCCVER}.tar.bz2 My rational is that it will produce a uclibc cross compiler using the user's current gcc version. Its likely to be downloaded and chances are that it is stable. Uclibc supports gcc-2.95 gcc-3.2 gcc-3.2.1 gcc-3.2.2 gcc-3.2.3 gcc-3.3 gcc-3.3.1 explictly although there is not that much difference between most of these and expansion should be very simple. Thoughts? Comments? Other options limit you to one version or not having the source available (unless of course I'm missing something) Solar - re comment 10 - thanks for this. I'm using it. comment 11 - SpanKY found CCHOST in the crosscompile.eclass. I'm using this eclass to do some verifications on flags and architectures. flag-o-matic.eclass seems to have some features to strip nonapplicable flags which I'll take a look at.
Very cool guys, I'm enjoying watching this bug mature. Just as a note (perhaps to myself) if/when using a pax enabled kernel and uClibc together that automatically emulate sigreturn trampolines should be enabled in the kernel.
uclibc-0.9.21 bumped to stable.
I keep forgetting to comment, but there must be a better way to call the uclibc wrapper without calling 'gcc-config -B' - that is just plain slow :( Actually - if you want to compile with uclibc, just go 'gcc-config whatever', as that will configure /usr/bin/gcc to call the right gcc, and thus no need for the 'sed -i -e "s:/usr/bin/gcc:`/usr/bin/gcc-config -B`/${CC}:" gcc-uClibc.h' hack ... all you also need to do is: # source /etc/profile Comments ?
The ebuild attached uses gcc-config -B get the true compiler as the current ebuild implementation of uclibc's gcc is a wrapper also. I got into trouble with the wrapper calling itself in previous attempts. I'm still working on making uclibc a native gcc compiler and it will use a gcc-config file like normal and should be then able to work with other ebuild without seding them. Yep I thoughly agree with your comments.
If we need gcc-config changes, let me know.
Martin - will do. Sorry for the delay guys - end of semester panic - all over in a week. I'll finish it off then. - If anyone wants a 1/2 completed draft just email me. BIG warning - its not finished!
For those of you wishing to help with uClibc support in gentoo please free to join #gentoo-embedded on irc.genoo.org
0.9.22 is in portage. Note: > On Mon, Nov 10, 2003 at 02:55:53AM -0700, Erik Andersen wrote: > > There comes a time when 90% of correct is not enough. uClibc has > > progressed enough that people had begin running into the wrapper > > limitations quite regularly. It seemed better to just kill off > > the wrapper and encourage people to use properly built > > toolchains.
0.9.23 ~arch is in portage with optional USE=etdyn support, this will soon become a config option in uClibc itself.
Well finally after much agony I've hopefully have a first draft of a workable toolchain for 0.9.23. On this December bugday I proudly present the install instruction: Step 1: Obtain a version of the buildroot toolchain. (ref http://www.uclibc.org/cvs_anon.html) cvs -d:pserver:anonymous@uclibc.org:/var/cvs login (no password) cvs -z3 -d:pserver:anonymous@uclibc.org:/var/cvs co -P buildroot tar -jcf /usr/portage/distfiles/buildroot-20031206.tar.bz2 buildroot Step 2: Take the ebuild uclibc-buildroot-0.9.23.ebuild and place it in your portage overlay directory (as package devlibs/uclibc-buildroot) Step 3: Download Something a bit odd about portage is you need the source to create a digest and you need a digest to download the source. emerge -pf uclibc-buildroot-0.9.23.ebuild Will list the file you need to download (excluding the buildroot which you already did a cvs tarball off) Place these in your $DISTFILE directory /usr/portage/distfiles This also uses the uclibc patches so: #cp -a /usr/portage/dev-libs/uclibc/files /usr/local/portage/dev-libs/uclibc-buildroot/ Step 4: env USE="+debug +nommu +nls" ebuild uclibc-buildroot-0.9.23.ebuild digest Step 5: env USE="+debug {insert other options here)" ebuild uclibc-buildroot-0.9.23.ebuild install USE options are: Global use flags debug - required to install a selfcontained root filesystem nls - Multilanguage support ipv6 - IPv6 support Local use flags nommu = No memory management unit on target architecture fullrpc = defines xdr functions and some lesser used rpc stuff. Required for NFS etdyn = apply etdyn patch An environment variable you may want to play with is TARGET_ARCH. Set this to the architecture you wish to compile for. Examples (untested however listed in uclibc doco): i386 arm mips mipsel As per make file: # Busybox link failing due to needing libgcc functions that are statics. #ARCH:=cris # The following currently fail to build since no shared lib support. #ARCH:=sh64 #ARCH:=m68k #ARCH:=v850 #ARCH:=sparc Sorry guys I'm not smart enough to fix there however the smart people at uclibc.org and their contributors are. Possibly good scope for inclusion in next version. The way it works: This makes its own set of binutils and hacks a version of gcc and installs them in /usr/${ARCH}-uclibc/.... A gcc config profile is created so to select it: #gcc-config ${ARCH}-uclibc-0.9.23 and #source /etc/profile to update the environment. BIG FAT WARNING: 1. change this back before you do any other emerges 2. Do not install to / 2.1 Use env ROOT=/var/lib/root_${ARCH} emerge.... to install in the root filesystem created. 2.2 Take note of bug 34887 and ALWAYS do a pretend install to make sure its going to put it in the right directory. The root filesystem: Using the debug mode (USE +debug) I've made this ebuild create a busybox/tinylogin/uclibc root filesystem in the /var/lib/root_${ARCH}. This is ideal for packing up and testing. This is a filesystem that is design to me all self contained so run it in a root jail (chroot /var/lib/root_${ARCH} /bin/ash). env ROOT=/var/lib/root_${ARCH} emerge (package) should install it in this directory for testing. see WARNINGS and bug 34887 (I hope I have been very clear on this) What I have tested: I have tested that it compiles with all options (USE nommu not tested that much yet) i386 architecture. And attempted small packages like hdparam. (ok this isn't that much) Release notes: This is still work in progress. The ebuild proces is currently interactive and askes for specific options at the beginning of the compile process (specific architecture and SAY yes to the siglist otherwise busybox will fail (to be fixed next busybox release). Things I intend to fix: 1. no longer interactive 2. a fuller list of use flags to support the multitude options that uclibc supports 3. There is a duplicate install process (to ${S}/staging_dir during the compile and ${D} in the install) that need emiminating 4. There is a small amount of unpacking in the compile process (nommu and nls options) that I may attempt to get moved into the unpack method 5. any other bugs submitted (I'm current just testing it with the latest cvs version so the ebuild should be attached soon). Any problems throw a comment here or try to catch me on #gentoo-embedded irc (in that order please). When you do attach a comment here please leave your configuration options USE and TARGET_ARCH if applicable. As per policy please incude unified patches (diff -u) if you improve/fix this ebuild.
Created attachment 21788 [details] uclibc-buildroot-0.9.23.ebuild
Bad logic around "use debug && emake busybox... || die" causes the lack of the debug flag to fail. Please use with debug flag in the meantime. I'm currently working on makeing the process non-interactive. Thankyou to david@futuretel.com for pointing it out to me.
Still working on it - draft in portage thats broken.
this could be an interesting bug thread for Peter Mazinger who is a developer dealing with ucLibc too.
Too hard. Must be doing it the wrong way. Too many reasons as to why it doesn't work. Will try another way.
