On Fri 10 Aug 2007 16:36, Rob Landley pondered: > On Thursday 09 August 2007 8:19:02 pm Robin Getz wrote: > > Why not use the toolchain/uClibc at blackfin.uclinux.org? > > > > https://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&pat > >h=%2Ftrunk%2F > > I'm my case I'm trying to build a dozen or so different platforms from the > same source code. Needing to grab a different toolchain for a given platform > means that platform is broken.
broken for you - sure. But this type of thing is pretty common in the noMMU world - it is not nice - but common :( We are trying to fix that. > (Just FYI. I poked you about this at OLS and you said it'd be six months > before all the various bits drifted upstream. Hasn't been six months yet, > and I've been busy with documentation...) We are working on this - but are just not quite there yet. > > - build multiple versions of uClibc > > For flat and for non-flat? There are a few versions that we build. The best way to understand things (if you care) is to look at our buildscript - which at the end of the day - is why crosstool exists, and why we maybe should have done it that way. http://blackfin.uclinux.org/gf/project/toolchain/scmsvn/?action=browse&path=%2Ftrunk%2Fbuildscript%2FBuildToolChain&revision=1754&view=markup It boils down all the multi-lib support, plus functional differences to handle issues in some older silicon (with bugs) this is for fdpic, and flat. Our buildscript takes a _long_ time now. It builds uClibc with/for: bf532-none;@mcpu=bf532-none bf532-0.3;@mcpu=bf532-0.3 mid-shared-library;@mid-shared-library msep-data;@msep-data mfdpic;@mfdpic mid-shared-library/mleaf-id-shared-library;@[EMAIL PROTECTED] bf532-none/mid-shared-library;@[EMAIL PROTECTED] bf532-none/msep-data;@[EMAIL PROTECTED] bf532-none/mfdpic;@[EMAIL PROTECTED] bf532-none/mid-shared-library/mleaf-id-shared-library;@[EMAIL PROTECTED]@mleaf-id-shared-library bf532-0.3/mid-shared-library;@[EMAIL PROTECTED] bf532-0.3/msep-data;@[EMAIL PROTECTED] bf532-0.3/mfdpic;@[EMAIL PROTECTED] bf532-0.3/mid-shared-library/mleaf-id-shared-library;@[EMAIL PROTECTED]@mleaf-id-shared-library Then it builds up the toolchain again - pointing gcc to the just built uClibcs. > > > - build bfin-uclinux- toolchain (for flat apps) > > - build bfin-linux-uclibc- toolchain (for fdpic) > > Huh, I wonder what an fdpic is... Probably not the Federal Data Protection > and Information Commissioner (first hit)... Goggling for "fdpic blackfin" > has this as the first reasonable hit: > > http://docs.blackfin.uclinux.org/doku.php?id=simple_hello_world_application_example_asm > > Which uses it but isn't about it... fdpic was orginally done for noMMU FRV, by Alexandre Oliva, and the nice folks at RedHAT - we just copied them. Although it is listed on: http://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels#Binary_format_support it doesn't have it's own page, and I forget what it stands for. Alexandre decided (rightly so) that the limitations of flat files for noMMU suck, and fdpic is as close to elf as you can be, without running with virtual memory. It provides Position Independent Code and Dynamic Shared Objects. http://www.gtlib.gatech.edu/pub/redhat/gnupro/FRV/FDPIC-ABI.txt http://docs.blackfin.uclinux.org/doku.php?id=:gcc_and_gas&s=fdpic%20stands#differences_between_blackfin_compilers http://docs.blackfin.uclinux.org/doku.php?id=:elf_and_flat http://docs.blackfin.uclinux.org/doku.php?id=:application_binary_interface#fdpic_run_time > > > Does anybody have any pointers where I can find sources, patches or > > > configs to get a uclibc build to complete? > > > > I do this daily with the sources from blackfin.uclinux.org - and don't have > > a problem. What does the uClibc version there not support, that you want to > > build your own with? > > I continue to want to build multiple platforms from the same source. If I > can't do that, the platform is not yet supported. By definition. Not yet supported by you is not equal to not supported by me :) But - yes - I agree - we have heard similar things from other distribution vendors who want to include our stuff, and are having a hard time. We are working on getting it resolved. It is taking more time that anyone would like. I was hoping on the end of this calendar year, but this is taking longer than expected. -Robin _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
