[uClibc-cvs] uClibc/docs/uclibc.org FAQ.html, 1.19, 1.20 index.html, 1.75, 1.76
Erik Andersen
andersen at uclibc.org
Thu Nov 13 12:45:57 UTC 2003
Update of /var/cvs/uClibc/docs/uclibc.org
In directory winder:/tmp/cvs-serv14387/docs/uclibc.org
Modified Files:
FAQ.html index.html
Log Message:
Prepare for release
Index: index.html
===================================================================
RCS file: /var/cvs/uClibc/docs/uclibc.org/index.html,v
retrieving revision 1.75
retrieving revision 1.76
diff -u -d -r1.75 -r1.76
--- index.html 8 Nov 2003 08:48:33 -0000 1.75
+++ index.html 13 Nov 2003 12:45:53 -0000 1.76
@@ -116,6 +116,38 @@
<ul>
<p>
+ <li> <b>13 November 2003, uClibc 0.9.23 Released</b>
+ <br>
+
+ CodePoet Consulting is pleased to announce the immediate availability of
+ uClibc 0.9.23. Of course, we are somewhat less than pleased that there
+ were configuration problems in the previous release that made such it
+ necessary to release .23 so quickly. Updated uClibc development systems
+ using uClibc 0.9.23 are being built and will be posted shortly. And Erik
+ has built Debian stable (woody) for x86 with uClibc and it runs great.
+
+ <p>
+
+ This release continues to be binary compatible with uClibc 0.9.21 and
+ 0.9.22 -- as long as you pick compatible configuration options. Enabling
+ or disabling things like soft-float, locale, wide char support, or changing
+ cpu optimizations are all good examples of binary incompatible
+ configuration options. If have changed any of those sorts of options (or
+ if you are not sure!) you will need to recompile all your applications and
+ libraries.
+
+ <p>
+
+ As usual, the
+ <a href="http://www.uclibc.org/downloads/Changelog">Changelog</a>,
+ <a href="http://www.uclibc.org/downloads/Changelog.full">detailed changelog</a>,
+ and <a href="http://www.uclibc.org/downloads/uClibc-0.9.23.tar.bz2">source code for this release</a>
+ are available <a href="http://www.uclibc.org/downloads/">here</a>.
+
+ <p>
+
+
+ <p>
<li> <b>8 November 2003, uClibc 0.9.22 Released</b>
<br>
Index: FAQ.html
===================================================================
RCS file: /var/cvs/uClibc/docs/uclibc.org/FAQ.html,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -d -r1.19 -r1.20
--- FAQ.html 5 Nov 2003 01:08:25 -0000 1.19
+++ FAQ.html 13 Nov 2003 12:45:53 -0000 1.20
@@ -53,8 +53,8 @@
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- Currently uClibc runs on alpha, ARM, cris, h8300, i386, i960, m68k,
- mips, PowerPC, SH, SPARC, and v850 processors.
+ Currently uClibc runs on alpha, ARM, cris, i386, i960, h8300,
+ m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors.
<p>
@@ -193,8 +193,8 @@
Using shared libraries makes complying with the license easy. You can
distribute a closed source application which is linked with an unmodified
uClibc shared library. In this case, you do not need to give away any
- source code for your application or for the uClibc library. Please
- consider sharing some of the money you make with us! :-)
+ source code for your application. Please consider sharing some of the
+ money you make with us! :-)
<p>
If you make any changes to uClibc, and distribute uClibc or distribute any
@@ -220,7 +220,7 @@
Sure! In fact, this can be very nice during development. By
installing uClibc on your development system, you can be sure that
- the code you are working on will actually run when you deploy it
+ the code you are working on will actually run when you deploy it on
your target system.
@@ -234,8 +234,8 @@
<TR><TD BGCOLOR="#eeeee0">
Yes. uClibc has native shared library support on i386, ARM, mips,
- SH, CRIS, and PowerPC processors. Other architectures can use shared libraries
- but will need to use the GNU libc shared library loader.
+ SH, CRIS, and PowerPC processors. Other architectures can use shared
+ libraries but will need to use the GNU libc shared library loader.
<p>
Shared Libraries are not currently supported by uClibc on MMU-less systems.
<a href="http://www.snapgear.com/">SnapGear</a> has implemented
@@ -251,16 +251,15 @@
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- The easiest way is to use the compiler wrapper built by uClibc. Instead of
- using your usual compiler or cross compiler, you can use i386-uclibc-gcc,
- (or whatever is appropriate for your target architecture) and your
- applications will auto-magically link against uClibc. You can also
- build your own native uClibc toolchain. Just download the uClibc toolchain
- builder from
+ You will need to have your own uClibc toolchain (i.e. GNU binutils and
+ gcc configured to produce binaries linked with uClibc).
+ You can build your own native uClibc toolchain using the uClibc
+ toolchain builder from
<a href="/cgi-bin/cvsweb/toolchain/">uClibc toolchain builder</a>,
or the uClibc buildroot system from
- <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>,
- adjust the Makefile settings to match your target system, and then run 'make'.
+ <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>.
+ Simply adjust the Makefile settings to match your target system,
+ and then run 'make'.
<p>
If you want to be <em>really</em> lazy and start using uClibc right
away without needing to compile your own toolchain or anything, you can
@@ -272,15 +271,15 @@
<a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_arm.bz2">arm</a>.
These are pre-built uClibc only development systems (created using
<a href="/cgi-bin/cvsweb/buildroot/">buildroot</a>), and provide a
- really really easy way to get started. These are about 20 MB bzip2
- compressed ext2 filesystems containing all the development software you
- need to build your own uClibc applications. With bash, awk, make, gcc, g++,
- autoconf, automake, ncurses, zlib, openssl, openssh, gdb, strace, busybox,
- GNU coreutils, GNU tar, GNU grep, etc, these should have pretty much everything
+ really really easy way to get started. These are about bzip2 compressed
+ ext2 filesystems containing all the development software you need to build
+ your own uClibc applications. With bash, awk, make, gcc, g++, autoconf,
+ automake, ncurses, zlib, openssl, openssh, gdb, strace, busybox, GNU
+ coreutils, GNU tar, GNU grep, etc, these should have pretty much everything
you need to get started building your own applications linked against
uClibc. You can boot into them, loop mount them, dd them to a spare drive
- and use resize2fs to make them fill a partition... Whatever works best
- for you.
+ and use resize2fs to make them fill a partition... Whatever works best for
+ you.
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
@@ -311,17 +310,13 @@
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
- First run
- <pre>export PATH=/usr/i386-linux-uclibc/bin:$PATH</pre>
- (or similar adjusted for your target architecture) then run you can simply
- run autoconf/automake and it should _just work_. Unfortunately, a large
- number of configure scripts (such as the one from openssh) try to execute
- test applications using your target C library, even if you are cross-
- compiling. This is bad, since it will prevent these programs from compiling.
- You need to complain to the authors of these programs and ask them to fix
- their broken configure scripts.
-
-
+ When you are cross-compiling, autoconf and automake are known to behave
+ badly. This is because a large number of configure scripts (such as the
+ one from openssh) try to actually execute applications that were cross
+ compiled for your target system. This is bad, since of course these won't
+ run, and this will also prevent your programs from compiling. You need to
+ complain to the authors of these programs and ask them to fix their broken
+ configure scripts.
<p>
@@ -387,40 +382,35 @@
I had for some time been despairing over the state of C libraries in Linux.
GNU libc, the standard, is very poorly suited to embedded systems and
has been getting bigger with every release. I spent quite a bit of time looking over the
- available Open Source C libraries that I knew of (listed below), and none of them really
+ available Open Source C libraries that I knew of, and none of them really
impressed me. I felt there was a real vacancy in the embedded Linux ecology.
The closest library to what I imagined an embedded C library should be was
uClibc. But it had a lot of problems too -- not the least of which was that,
- traditionally, uClibc had a complete source tree fork in order to support each
- and every new platform. This resulted in a big mess of twisty versions, all
- different. I decided to fix it and the result is what you see here.
- My source tree has now become the official uClibc source tree and it now lives
- on cvs.uclinux.org and www.uclibc.org.
+ traditionally, uClibc required a complete source tree fork in order to support
+ each and every new platform. This resulted in a big mess of twisty versions,
+ all different. I decided to fix it and the result is what you see here.
<p>
To start with, (with some initial help from <a
href="http://www.uclinux.org/developers/">D. Jeff Dionne</a>), I
- ported it to run on i386. I then grafted in the header files from glibc 2.1.3
+ ported uClibc to run on i386. I then grafted in the header files from glibc
and cleaned up the resulting breakage. This (plus some additional work) has
- made it almost completely independent of kernel headers, a large departure from
+ made it much less dependant on kernel headers, a large departure from
its traditional tightly-coupled-to-the-kernel origins. I have written and/or
rewritten a number of things that were missing or broken, and sometimes grafted
- in bits of code from the current glibc and libc5. I have also built a proper
- platform abstraction layer, so now you can simply edit the file "Config" and
- use that to decide which architecture you will be compiling for, and whether or
- not your target has an MMU, and FPU, etc. I have also added a test suite,
- which, though incomplete, is a good start. Several people have helped by
- contributing ports to new architectures, and a lot of work has been done on
- adding support for missing features.
+ in bits of code from the current glibc and libc5. I have also added a proper
+ configuration system which allows you to easily select your target architecture
+ and enable and disable various features. Many people have helped by testing,
+ contributing ports to new architectures, and adding support for missing features.
<p>
In particular, around the end of 2000, Manuel Novoa III got involved with
- uClibc. One of his first contributions was the original gcc wrapper.
- Since then, he has written virtually all of the current uClibc stdio, time,
- string, ctype, locale, and wchar-related code, as well as much of stdlib
- and various other bits throught the library.
+ uClibc. One of his first contributions was the original gcc wrapper (which
+ has since been removed). Since then, he has written virtually all of the
+ current uClibc stdio, time, string, ctype, locale, and wchar-related code,
+ as well as much of stdlib and various other bits throught the library.
<p>
@@ -442,7 +432,7 @@
<TR><TD BGCOLOR="#eeeee0">
You have not paid us a single cent and yet you still have the
- product of nearly two years of work from Erik and Manuel and
+ product of several years of work from Erik and Manuel and
many other people. We are not your slaves! We work on uClibc
because we find it interesting. If you go off flaming us, we will
ignore you.
@@ -496,7 +486,7 @@
<p>
<TR><TD BGCOLOR="#ccccc0" ALIGN=left>
<B>
- Ok, I'm done reading all these questions.
+ Ok, I'm done reading all this stuff.
</B>
</TD></TR>
<TR><TD BGCOLOR="#eeeee0">
More information about the uClibc-cvs
mailing list