Subversion Repositories or1k

/news.html

/header.html

/other_libs.html

/lists.html

/footer.html

/images/fm.mini.png Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream

/images/fm.mini.png

images/fm.mini.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/ltbutton2.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/ltbutton2.png =================================================================== --- images/ltbutton2.png (nonexistent) +++ images/ltbutton2.png (revision 1765)

images/ltbutton2.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/dir.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/dir.png =================================================================== --- images/dir.png (nonexistent) +++ images/dir.png (revision 1765)

images/dir.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/written.in.vi.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/written.in.vi.png =================================================================== --- images/written.in.vi.png (nonexistent) +++ images/written.in.vi.png (revision 1765)

images/written.in.vi.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/sdsmall.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/sdsmall.png =================================================================== --- images/sdsmall.png (nonexistent) +++ images/sdsmall.png (revision 1765)

images/sdsmall.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/back.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/back.png =================================================================== --- images/back.png (nonexistent) +++ images/back.png (revision 1765)

images/back.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/vh40.gif =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/vh40.gif =================================================================== --- images/vh40.gif (nonexistent) +++ images/vh40.gif (revision 1765)

images/vh40.gif Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/text.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/text.png =================================================================== --- images/text.png (nonexistent) +++ images/text.png (revision 1765)

images/text.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/donate.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/donate.png =================================================================== --- images/donate.png (nonexistent) +++ images/donate.png (revision 1765)

images/donate.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: images/gfx_by_gimp.png =================================================================== Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: images/gfx_by_gimp.png =================================================================== --- images/gfx_by_gimp.png (nonexistent) +++ images/gfx_by_gimp.png (revision 1765)

images/gfx_by_gimp.png Property changes : Added: svn:mime-type ## -0,0 +1 ## +application/octet-stream \ No newline at end of property Index: uClibc-apps.html =================================================================== --- uClibc-apps.html (nonexistent) +++ uClibc-apps.html (revision 1765) @@ -0,0 +1,135 @@ + + + + + + + + + + + + + +

+ +

+ + + +

+ + µ C l i b c + +

+

+ + + + +
+When you are done, +you can click here to return to the uClibc home page. + + + +

+ + +

+ + uClibc -- NOT WORKING Application List + + +

+ + The following applications are known to NOT work with uClibc. Please +tell us if you know of any applications that fall into this category! + + +NOTE: because basically everything works with uClibc these days, we +have removed the old "WORKING Application List" and from now on will +only be adding items to the NOT WORKING list, + + + + + + + + + + + + + + + + + + + + + + + Program Version Comment Mozilla   Might actually work now. Someone care to give it a try? Dunno....   If you know of an application that does not work with uClibc, + PLEASE let us know! + + + + + + + +

+

+ + + + +

---

+ + + + + + + + + + + + + + + +

+ + Mail all comments, insults, suggestions and bribes to + Erik Andersen + +

+ +

+ +

+ +

+ +

+ +

+ + + + + + + + Index: toolchains.html =================================================================== --- toolchains.html (nonexistent) +++ toolchains.html (revision 1765) @@ -0,0 +1,52 @@ + + + +

Toolchains

+To use uClibc, you need to have a toolchain, which is composed +of binutils, +gcc, and of course uClibc. + +

+ +
• You can build your own + uClibc toolchain + using this to automagically download all the needed source code + and compile everything for you. +

  + +

• Steven J. Hill has kindly provided + RPMs and SRPMs + with toolchains for mips. +

  + +

• You can compile your own uClibc development system using + buildroot. +

  + +

• Prebuilt uClibc development systems for + i386 + and + arm + and + mipsel + are available and contain complete native gcc 3.3.2 toolchains. These + are development systems are ext2 filesystems that runs natively on the + specified architecture. They contain all the development software you + need to build your own uClibc applications, including bash, coreutils, + findutils, diffutils, patch, sed, ed, flex, bison, file, gawk, tar, + grep gdb, strace, make, gcc, g++, autoconf, automake, ncurses, zlib, + openssl, openssh perl, and more. And of course, everything is + dynamically linked against uClibc. By using a uClibc only system, you + can avoid all the painful cross-configuration problems that have made + using uClibc somewhat painful in the past. If you want to quickly get + started with testing or using uClibc you should give these images a + try. You can loop mount them and then chroot into them. You can boot + into them using user-mode Linux. You can even 'dd' them to a spare + partition and use resize2fs to make them fill the drive, and then boot + into them. Whatever works for you. +

  + +

+ + + Index: products.html =================================================================== --- products.html (nonexistent) +++ products.html (revision 1765) @@ -0,0 +1,30 @@ + + + +

Products/Projects Using uClibc

+ +Do you use uClibc? I'd love to know about it and I'd be happy to link to you. + +

+I know of the following products and/or projects that use uClibc -- +listed in the order I happen to add them to the web page: + +

+ + +
• buildroot a configurable +means for building your own busybox/uClibc based system systems. + +
• LEAF Bering-uClibc +
  the sucessor of the Linux Router Project, supporting all sorts of + gateways, routers, wireless routers, and firewalls. +
• Tuxscreen Linux Phone +
• Linksys WRT54G - Wireless-G Broadband Router +
• NetGear WG602 wireless router +
• Almost all the Axis network cameras use uClibc + +

+ + + + Index: cvs_write.html =================================================================== --- cvs_write.html (nonexistent) +++ cvs_write.html (revision 1765) @@ -0,0 +1,32 @@ + + + +

CVS Read/Write Access

+ +If you want to be able to commit things to CVS, first contribute some +stuff to show you are serious. Then, very nicely ask +Erik Andersen if he will set you up with +an account. To access CVS, you will want to add the following to set up your environment: +

    +$ export CVS_RSH=/usr/bin/ssh








    +$ export CVSROOT='username@cvs.uclibc.org:/var/cvs'

+
+It goes without saying you must change username to your own +username... +

+ +To obtain commit access, you will need to demonstrate you are +serious by submitting a few good patches first. Then, you will need to +select a user-name to use when committing stuff, and finally, you will +need to send me the username you have selected, an ssh key, and the email +address where you prefer email to be sent (I will forward any email sent +to you, but not store it). + +

+Note that if you would prefer to keep your communications with me +private, you can encrypt your email using my +public key. + + + + Index: cvs_anon.html =================================================================== --- cvs_anon.html (nonexistent) +++ cvs_anon.html (revision 1765) @@ -0,0 +1,57 @@ + + + +

Anonymous CVS

+ +We allow anonymous (read-only) CVS access to everyone. The first command you +need to run for anonymous CVS access is: +

    +cvs -d:pserver:anonymous@uclibc.org:/var/cvs login

+

+CVS will prompt you for a password. Just press the Enter key (there is no +password for anonymous access). This step only needs to be done once, the first +time you attempt to access CVS. +

+Once the login is complete, you can then check the list of available +CVS modules by running the following command (all on one line): +

    +cvs -z3 -d:pserver:anonymous@uclibc.org:/var/cvs co -c 

+ +

+If you wish, you can then check out a local copy of any of the +available modules. The following is an example of how to grab +a copy of uClibc: +

    +    cvs -z3 -d:pserver:anonymous@uclibc.org:/var/cvs co -P uClibc

+This will create a directory called uClibc in the current +directory. This directory will contain the latest and greatest source +code for uClibc. + +

+If you are not already familiar with using CVS, I recommend you visit +this quick Introduction to CVS. + +

+I usually create a ~/.cvsrc file with the following things in it, and I +recommend you should use the same: +

    +    -z3








    +    update -dP








    +    rdiff -u








    +    diff -ubBwpN








    +    checkout -P

+ +

+Once you've checked out a copy of the source tree, you can update your +source tree at any time so it is in sync with the latest and greatest by +running the command: +

    +cvs update

+ +Because you've only been granted anonymous access to the tree, you won't be +able to commit any changes. Changes can be submitted for inclusion by posting +them to the appropriate mailing list. For those that are actively contributing +CVS write access can be made available. + + + Index: FAQ.html =================================================================== --- FAQ.html (nonexistent) +++ FAQ.html (revision 1765) @@ -0,0 +1,466 @@ + + + +

Frequently Asked Questions

+ +This is a collection of some of the most frequently asked questions +about uClibc. Some of the questions even have answers. If you +have additions to this FAQ document, we would love to add them, + +

+
1. Why is it called uClibc? +
2. What platforms does uClibc run on? +
3. Why are you doing this? What's wrong with glibc? +
4. So uClibc is smaller then glibc? Doesn't that mean it + completely sucks? How could it be smaller and not suck? +
5. Why should I use uClibc? +
6. If I use uClibc, do I have to release all my source code to the world for + free? I want to create a closed source commercial application and I want + to protect my intellectual property. +
7. Can I use it on my x86 development system? +
8. Does uClibc support shared libraries? + +
9. How do I compile programs with uClibc? +
10. Is a pre-compiled uClibc development system available? +
11. Why do I keep getting "sh: can't access tty; job control + turned off" errors? Why doesn't Control-C work within my shell? +
12. How do I make autoconf and automake behave? +
13. When I run 'ldd' to get a list of the library dependencies + for a uClibc binary, ldd segfaults! What should I do? +
14. Why does localtime() return times in UTC even when I have my timezone set? +
15. What is the history of uClibc? Where did it come from? +
16. I demand that you to add <favorite feature> right now! How come + you don't answer all my questions on the mailing list instantly? I demand + that you help me with all of my problems Right Now! +
17. I need you to add <favorite feature>! Are the uClibc developers willing to + be paid in order to fix bugs or add in <favorite feature>? Are you willing to provide + support contracts? +
18. I think you guys are great and I want to help support your work! + + +

+ + +

---

+

+

Why is it called uClibc?

+

+ + The letter 'u' is short for µ (the greek letter "mu"). µ is commonly used + as the abbreviation for the word "micro". The capital "C" is short for + "controller". So the name uClibc is sortof an abbreviation for "the + microcontroller C library". For simplicity, uClibc is pronounced + "yew-see-lib-see". +

+ The name is partly historical, since uClibc was originally + created to support µClinux, a port of + Linux for MMU-less microcontrollers such as the Dragonball, Coldfire, and + ARM7TDMI. These days, uClibc also works just fine on normal Linux systems + (such as i386, ARM, and PowerPC), but we couldn't think of a better name. + +

---

+

+

What platforms does uClibc run on?

+

+ + + Currently uClibc runs on alpha, ARM, cris, i386, i960, h8300, + m68k, mips/mipsel, PowerPC, SH, SPARC, and v850 processors. + + +

---

+

+

Why are you doing this? What's wrong with glibc?

+

+ + Initially, the project began since the GNU C library lacked support for + MMU-less systems, and because glibc is very large. The GNU C library is + designed with a very different set of goals then uClibc. The GNU C library + is a great piece of software, make no mistake. It is compliant with just + about every standard ever created, and runs on just about every operating + system and architecture -- no small task! But there is a price to be paid + for that. It is quite a large library, and keeps getting larger with each + release. It does not even pretend to target embedded systems. To quote + from Ulrich Drepper, the maintainer of GNU libc: "...glibc is not the right + thing for [an embedded OS]. It is designed as a native library (as opposed + to embedded). Many functions (e.g., printf) contain functionality which is + not wanted in embedded systems." 24 May 1999 + + + +

---

+

+

So uClibc is smaller then glibc? Doesn't that mean it completely sucks? +How could it be smaller and not suck?

+

+

+ + uClibc and glibc have different goals. glibc strives for features + and performance, and is targeted for desktops and servers with + (these days) lots of resources. It also strives for ABI stability. + +

+ + On the other hand, the goal of uClibc is to provide as much functionality + as possible in a small amount of space, and it is intended primarily for + embedded use. It is also highly configurable in supported features, at the + cost of ABI differences for different configurations. uClibc has been + designed from the ground up to be a C library for embedded Linux. We don't + need to worry about things like MS-DOS support, or BeOS, or AmigaOs any + other system. This lets us cut out a lot of complexity and very carefully + optimize for Linux. + +

+ + In other cases, uClibc + leaves certain features (such as full C99 Math library support, wordexp, + IPV6, and RPC support) disabled by default. Those features can be enabled + for people that need them, but are otherwise disabled to save space. + +

+ + Some of the space savings in uClibc is obtained at the cost of performance, + and some is due to sacrificing features. Much of it comes from aggressive + refactoring of code to eliminate redundancy. In regards to locale data, + elimination of redundant data storage resulted in substantial space + savings. The result is a libc that currently includes the features needed + by nearly all applications and yet is considerably smaller than glibc. To + compare "apples to apples", if you take uClibc and compile in locale data + for about 170 UTF-8 locales, then uClibc will take up about 570k. If you + take glibc and add in locale data for the same 170 UTF-8 locales, you will + need over 30MB!!! + +

+ + The end result is a C library that will compile just about everything you + throw at it, that looks like glibc to application programs when you + compile, and is many times smaller. + + + +

---

+

+

Why should I use uClibc?

+

+ + I don't know if you should use uClibc or not. It depends on your needs. + If you are building an embedded Linux system and you are tight on space, then + using uClibc instead if glibc may be a very good idea. + +

+ + If you are building an embedded Linux system and you find that + glibc is eating up too much space, you should consider using + uClibc. If you are building a huge fileserver with 12 Terabytes + of storage, then using glibc may make more sense. Unless, for + example, that 12 Terabytes will be Network Attached Storage and + you plan to burn Linux into the system's firmware... + + + +

---

+

+

If I use uClibc, do I have to release all my source code to the world for + free? I want to create a closed source commercial application and I want + to protect my intellectual property.

+

+ + No, you do not need to give away your application source code just because + you use uClibc and/or run on Linux. uClibc is licensed under the Lesser GPL licence, just + like the GNU C library (glibc). Please read this licence, or have a lawyer + read this licence if you have any questions. Here is my brief summary... + 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. Please consider sharing some of the + money you make with us! :-) +

+ + If you make any changes to uClibc, and distribute uClibc or distribute any + applications using your modified version, you must also distribute the + source code for uClibc containing all of your changes. +

+ + If you distribute an application which has uClibc statically linked, you + must also make your application available as an object file which can later + be re-linked against updated versions of uClibc. This will (in theory) + allow your customers to apply uClibc bug fixes to your application. You do + not need to make the application object file available to everyone, just to + those you gave the fully linked application. + + +

---

+

+

Can I use it on my x86 development system?

+

+ + 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 on + your target system. + + + +

---

+

+

Does uClibc support shared libraries?

+

+ + 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. +

+ Shared Libraries are not currently supported by uClibc on MMU-less systems. + SnapGear has implemented + shared library support for MMU-less systems, however, so if you need MMU-less + shared library support they may be able to help. + + +

---

+

+

How do I compile programs with uClibc?

+

+ + 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 + uClibc toolchain builder, + or the uClibc buildroot system from + uClibc buildroot system. + Simply adjust the Makefile settings to match your target system, + and then run 'make'. + +

---

+

+

Is a pre-compiled uClibc development system available?

+

+ + If you want to be really lazy and start using uClibc right + away without needing to compile your own toolchain or anything, you can + grab a copy of the uClibc development systems, currently available for + i386, + powerpc, + arm, + mips, + mipsel, and + sh4. + The powerpc dev system mostly works, but there is still some sortof + problem with the shared library loader that has not yet been resolved. + +

+ These are pre-built uClibc only development systems (created using + buildroot), and provide a + 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. + +

+ The quickest way to get started using a root_fs image (using the i386 + platform as an example) is: +

+
• Download root_fs_i386.bz2 from kernel.org
+
• bunzip2 root_fs_i386.bz2
+
• mkdir root_fs
+
• su root
+
• mount -o loop root_fs_i386 root_fs
+
• chroot root_fs /bin/sh
+

+ Type "exit" to end the chroot session and return to the host system. +

+ + + +

---

+

+

Why do I keep getting "sh: can't access tty; job control + turned off" errors? Why doesn't Control-C work within my shell?

+

+ + This isn't really a uClibc question, but I'll answer it here anyways. Job + control will be turned off since your shell can not obtain a controlling + terminal. This typically happens when you run your shell on /dev/console. + The kernel will not provide a controlling terminal on the /dev/console + device. Your should run your shell on a normal tty such as tty1 or ttyS0 + and everything will work perfectly. If you REALLY want your shell + to run on /dev/console, then you can hack your kernel (if you are into that + sortof thing) by changing drivers/char/tty_io.c to change the lines where + it sets "noctty = 1;" to instead set it to "0". I recommend you instead + run your shell on a real console... + + +

---

+

+

How do I make autoconf and automake behave?

+

+ + 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. + + +

---

+

+

When I run 'ldd' to get a list of the library dependencies + for a uClibc binary, ldd segfaults! What should I do?

+

+ + Use the ldd that is built by uClibc, not your system's one. When your + system's ldd looks for library dependencies, it actually _runs_ that + program. This works fine -- usually. It generally will not work at all + when you have been cross compiling (which is why ldd segfaults). The ldd + program created by uClibc is cross platform and doesn't even try to run + the target program (like your system one does). So use the uClibc one + and it will do the right thing, and it won't segfault even when you are + cross compiling. + + +

---

+

+

Why does localtime() return times in UTC even when I have my timezone set?

+

+ + + The uClibc time functions get timezone information from the TZ environment + variable, as described in the Single Unix Specification Version 3. See + + http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html + for details on valid settings of TZ. For some additional examples, read + + http://www.uclibc.org/lists/uclibc/2002-August/006261.html in the uClibc + mailing list archive. + You can store the value of TZ in the file '/etc/TZ' and uClibc will then + automagically use the specified setting. + + +

---

+

+

What is the history of uClibc? Where did it come from?

+

+ + + The history and origin of uClibc is long and twisty. + In the beginning, there was GNU libc. Then, libc4 + (which later became linux libc 5) forked from GNU libc version 1.07.4, with + additions from 4.4BSD, in order to support Linux. Later, the Linux-8086 C library, which is part of + the elks project, was created, + which was, apparently, largely written from scratch but also borrowed code from + libc4, glibc, some Atari library code, with bits and pieces from about 20 other + places. Then uClibc forked off from the Linux-8086 C library in order to run + on µClinux. +

+ + 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, 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 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. + +

+ + To start with, (with some initial help from D. Jeff Dionne), I + 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 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 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. + +

+ + In particular, around the end of 2000, Manuel Novoa III got involved with + 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. + +

+ + These days, uClibc is being developed and enhanced by Erik Andersen + and Manuel Novoa III of + CodePoet Consulting + along with the rest of the embedded Linux community. + + + +

---

+

+

I demand that you to add <favorite feature> right now! How come + you don't answer all my questions on the mailing list instantly? I demand + that you help me with all of my problems Right Now!

+

+ + You have not paid us a single cent and yet you still have the + 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. + + + + +

---

+

+

I need you to add <favorite feature>! Are the uClibc developers willing to + be paid in order to fix bugs or add in <favorite feature>? Are you willing to provide + support contracts?

+

+ + Sure! Now you have our attention! What you should do is contact Erik Andersen of CodePoet Consulting to bid + on your project. If Erik is too busy to personally add your feature, there + are several other active uClibc contributors who will almost certainly be able + to help you out. Erik can contact them and ask them about their availability. + + +

---

+

+

I think you guys are great and I want to help support your work!

+

+ + Wow, that would be great! You can click here to help support uClibc and/or request features. + + +

+

+ + + + + + +

+ + + + If you prefer to contact us directly for payments, hardware donations, + support requests, etc., you can contact + CodePoet Consulting here. + +

---

+ + + + Index: download.html =================================================================== --- download.html (nonexistent) +++ download.html (revision 1765) @@ -0,0 +1,32 @@ + + + + +

Download

+ +Source for the latest release can always be +downloaded from http://www.uclibc.org/downloads + +

+You can also obtain Daily Snapshots of +the latest CVS source tree for those wishing to follow uClibc development, +but cannot or do not wish to use CVS. + +

+ +

+
• Click here to + browsable the CVS tree. +
+ +
• Anonymous CVS access is available. +
+ +
• For those that are actively contributing there is + even CVS write access. +
+ +

+ + + Index: index.html =================================================================== --- index.html (nonexistent) +++ index.html (revision 1765) @@ -0,0 +1 @@ + Index: about.html =================================================================== --- about.html (nonexistent) +++ about.html (revision 1765) @@ -0,0 +1,99 @@ + + + + + +

A C library for embedded Linux

+ +uClibc (aka µClibc/pronounced yew-see-lib-see) is a C library for developing +embedded Linux systems. It is much smaller than the GNU C Library, but nearly +all applications supported by glibc also work perfectly with uClibc. Porting +applications from glibc to uClibc typically involves just recompiling the +source code. uClibc even supports shared libraries and threading. It currently +runs on standard Linux and MMU-less (also known as µClinux) systems with +support for alpha, ARM, cris, i386, i960, h8300, m68k, mips/mipsel, PowerPC, +SH, SPARC, and v850 processors. + +

+ +If you are building an embedded Linux system and you find that +glibc is eating up too much space, you may want to consider using +uClibc. If you are building a huge fileserver with 12 Terabytes +of storage, then using glibc may make more sense. Unless, for +example, that 12 Terabytes will be Network Attached Storage and +you plan to burn Linux into the system's firmware... + +

+ +uClibc is maintained by Erik Andersen +and is licensed under the +GNU LIBRARY GENERAL PUBLIC LICENSE +. This license allows you to make closed source commercial applications using +uClibc. (Please consider sharing some of the money you make ;-). You do not need +to give away all your source code just because you use uClibc and/or run on Linux. +See the list of Frequently Asked Questions for details. + +

+ +

Sponsors

+ +Please visit our sponsors and thank them for their +support! They have provided money for equipment and +bandwidth. Next time you need help with a project, +consider these fine companies! + + +

+
• Penguru Consulting
  + Custom development for embedded Linux systems and multimedia platforms +
+ +
• opensource.se
  + Embedded open source consulting in Europe. +
+ +
• Codepoet Consulting
  + Custom Linux, embedded Linux, BusyBox, and uClibc + development. +
+ +

+ +If you wish to be a sponsor, or if you have already contributed and would like +your name added here, email Erik. + +

+

+ + + + + + + +

+Do you like uClibc? Do you need support? Do you need some features +added? Then why not help out? We are happy to accept donations +(such as bandwidth, mirrors sites, and hardware for the various +architectures). We can also provide support contracts, and implement +funded feature requests. To contribute, you can either click on the +Donate image to donate using PayPal, or you can contact Erik at +CodePoet Consulting +(we have a credit card machine so you can avoid PayPal if you wish). +

+ + + + + + + + + +

+ + + Index: oldnews.html =================================================================== --- oldnews.html (nonexistent) +++ oldnews.html (revision 1765) @@ -0,0 +1,995 @@ + + + +

+ + +
• 13 November 2003, uClibc 0.9.23 Released +
  + + 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. + +

  + + 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. + +

  + + As usual, the + Changelog, + detailed changelog, + and source code for this release + are available here. + +

  + + +

  +

• 8 November 2003, uClibc 0.9.22 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.22. This release has been cooking for a couple of months now + and is looking quite solid. We have done quite a lot of testing with this + release and things are looking good. And Erik has built Debian stable + (woody) for x86 with uClibc and it runs great. Expect that to be released + in the next few days. + +

  + + This release is binary compatible with uClibc 0.9.21 -- 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. + +

  + + Updated uClibc development systems using uClibc 0.9.22 will be made + available within a few days. Meanwhile, we invite you to try out uClibc + with the latest Linux Test Project + test suite (you will need to apply a small patch. + And also give the latest Perl and Python test suites a try as well. + If you find any bugs in uClibc, PLEASE let us know! +

  + + As usual, the + Changelog, + detailed changelog, + and source code for this release + are available here. + +

  + + +

  +

• 30 September 2003, dev systems updated to uClibc 0.9.21+ +
  + + The uClibc development systems for + i386, + powerpc, + arm, + mips, + have been updated to uClibc 0.9.21 (plus all the CVS updates up to + today). Several problems have been fixed up, + gcc has been updated to version 3.3.1, binutils was updated to 2.14.90.0.6, and + tada everything finally works for cross compiling. These were + all cross compiled (which really makes things faster since the older + mipsel releases used to take 2 days to build!) + +

  + These are ~100 MB ext2 filesystems that run natively on the specified + architecture. They contains all the development software you need to build + your own uClibc applications, including bash, coreutils, findutils, + diffutils, patch, sed, ed, flex, bison, file, gawk, tar, grep gdb, strace, + make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh perl, + and more. And of course, everything is dynamically linked against uClibc. + By using a uClibc only system, you can avoid all the painful + cross-configuration problems that have made using uClibc somewhat painful + in the past. If you want to quickly get started with testing or using + uClibc you should give these images a try. You can loop mount and them + you can chroot into them, you can boot into with using user-mode Linux, + and you can even 'dd' them to a spare partition and use resize2fs to make + them fill the drive. Whatever works for you. + +

  If you would like to build your own custom uClibc system, you can + use buildroot, which is + how these uClibc development systems were created. +

  + + +

  +

• 9 September 2003, uClibc 0.9.21 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.21. This release has been brewing for several months now, and + provides quite a lot of additional functionality and quite a few bug fixes + as well. Many people will be pleased that this release fixes the + "dlopen()'ing libraries that depend on libraries" problem. + +

  + + The biggest thing in this release (and I do mean that literally) is that + uClibc now has full ANSI/ISO C99 locale support. Well, except for + wcsftime() and collating items in regex, which are not done yet. Adding + support for the default set of locales (169 UTF-8 locales and 144 locales + using other codesets) will enlarge uClibc by around 300k. Still, if you + need locale support, that is still much better than the roughly 30MB the + comparable set of locale date occupies with glibc. And you can of course + reduce the 300k by reducing the number of supported locales. + +

  + + As usual, this release has many improvements, both large and small. At + this point, most applications that compile and work with glibc will also + compile and run with uClibc. Both Perl and Python pass all the tests in + their test suites (both with and without locale support enabled). We + invite you to grab a copy of the latest Linux Test Project test suite and + give uClibc some abuse. We are not yet perfect, but we are getting pretty + darn close. + +

  + + This release is not binary compatible with earlier releases. Depending on + your configuration, you may actually still be binary compatible, but it + would be a good idea to recompile your applications when moving to the + uClibc 0.9.21 release. We are sorry about that, but we have never promised + to provide binary compatibility until we hit version 1.0. And even then, + if you change your uClibc configuration, you still still generally need to + recompile... + +

  + + As usual, the + Changelog, + detailed changelog, + and source code for this release + are available here. + +

  + + Updated uClibc development systems using uClibc 0.9.21 will be made + available within a few days. +

  + + +

  +

• 30 June 2003, uClibc 0.9.20 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.20. This is primarily a bug-fix release. This release remains + binary compatible with 0.9.18 and 0.9.19 (as long as you leave the + new UCLIBC_HAS_TM_EXTENSIONS option disabled), so you don't have to recompile + everything if you don't really feel like it. +

  + + This release has many small improvements. At this point, most applications + that compile and work with glibc will also compile and run with uClibc. + Perl and Python even pass all the tests in their test suites. +

  + + There is currently one notable exception. Applications that use dlopen() + to load libraries that themselves depend on other libraries, may have weak + symbols within those depended-upon libraries resolved incorrectly. This + problem is currently being worked on. Other than that, everything seems + to now be working as expected.... + +

  + As usual, the + Changelog, + detailed changelog, + and source code for this release + are available here. +

  + + +

  +

• 30 June 2003, dev systems updated to uClibc 0.9.20 +
  + + The uClibc development systems for + i386, + powerpc, + arm, + mips, + have been updated to uClibc 0.9.20. Several problems have been fixed up, + gcc has been updated to version 3.3, and Perl 5.8.0 is now included. +

  + + This is a 150 MB ext2 filesystem that runs natively on the specified + architecture. It contains all the development software you need to build + your own uClibc applications, including bash, coreutils, findutils, + diffutils, patch, sed, ed, flex, bison, file, gawk, tar, grep gdb, strace, + make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh perl, + and more. And of course, everything is dynamically linked against uClibc. By + using a uClibc only system, you can avoid all the painful + cross-configuration problems that have made using uClibc somewhat painful + in the past. If you want to quickly get started with testing or using + uClibc you should give these images a try. You can loop mount and then + chroot into them, you can boot into them using user-mode Linux, and you can + even 'dd' them to a spare partition and use resize2fs to make them fill the + drive. Whatever works for you. + +

  If you would like to build your own custom uClibc system, you can + use buildroot, which is + how the uClibc development systems were created. +

  + + +

  +

• 6 March 2003, development system updates +
  + + The uClibc development systems for + i386, + powerpc, + arm, + and now for the first time + mips, + have been updated to uClibc 0.9.19. Several smaller problems + have also been fixed up. +

  + + This is an ext2 filesystem that runs natively on the specified + architecture. It contains all the development software you need to build + your own uClibc applications, including bash, coreutils, findutils, + diffutils, patch, sed, ed, flex, bison, file, gawk, tar, grep gdb, strace, + make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh and + more. And of course, everything is dynamically linked against uClibc. By + using a uClibc only system, you can avoid all the painful + cross-configuration problems that have made using uClibc somewhat painful + in the past. If you want to quickly get started with testing or using + uClibc you should give these images a try. You can loop mount and + then chroot into them, you can boot into them using user-mode Linux, + you can even 'dd' them to a spare partition and use resize2fs to + make them fill the drive. Whatever works best for you. +

  + + Have Fun. +

  + + +

  +

• 3 March 2003, uClibc 0.9.19 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.19. This is once again primarily a bug-fix release. Several + critical problems with system calls were fixed, the pthreads library was + improved, debugging of applications using uClibc's pthreads library is + now possible (requires gdb 5.3 or newer that is compiled using uClibc), + and a number of other random fixes are included. This release retains + binary compatibility with uClibc 0.9.18 (except for mips, which didn't + work properly with uClibc 0.9.18 anyways). Updated development system + images compiled with uClibc 0.9.19 will be released shortly. + +

  + As usual, the + Changelog and source code for this release + are available here. +

  + + + + +

  +

• 17 February 2003, development system updates +
  + + The uClibc development systems for + i386 + and + powerpc, + and + arm + have been again updated. This time around a few broken symlinks + (one preventing C++ code from compiling) have been fixed, several + system calls related to uids and gid have been fixed, the powerpc + system call mechanism has been updated, and GNU tar and GNU grep + have been added. gcc, gcc+, ssh, etc are all still included and + things remain binary compatible with uClibc 0.9.18. + Have Fun. +

  + + +

  +

• 12 February 2003, development system updates +
  + + The uClibc development system has had a number of problems + fixed, and has been updated for uClibc 0.9.18. The + i386 + and + powerpc, + and + arm + devel systems are updated and ready to download and use. + Have Fun. +

  + + +

  +

• 12 February 2003, uClibc 0.9.18 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.18. This is primarily a bug-fix release, as there were a few + directory handling problem that could cause application using uClibc 0.9.17 + to either segfault or lose the first character when reading directry names. + Unfortunately, once again, this release is _NOT_ binary compatible with + earlier uClibc releases. I _think this will be the last time (with the + possible exception of some future changes to our locale support...) + +

  + As usual, the + Changelog + and source code + for this release are available here. + You might want to download uClibc from the closest + kernel.org mirror site. + Just pick the closest mirror site, and then go to + + http://www.XX.kernel.org/pub/linux/libs/uclibc/ + to download uClibc, where XX is your two letter country code. +

  +

  + +

  +

• 25 January 2003, uClibc 0.9.17 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.17. The biggest piece of news with this release, thanks to + Manuel Novoa's continuing hard work, is that we now have fully standards + compliant locale support (optional of course). The support works nicely, + (though configuring the locales you wish to support is still manual -- a + task for the next release). Full locale data for over 300 locales adds + approximately 250k. The collation data for all supported locales is + roughly 180k. This may seem rather large to some -- but it is much smaller + than the approximately 40 MB needed by Glibc to provide the same data. And + if you don't need it, you can either disable locale support entirely, or + enable a smaller set of locales. + +

  + + This release also fixes lots and lots of bugs. The arm + architecture support (I am embarrassed to note) was totally broken in the + last release, but is now working as expected. A security problem (a + buffer overflow in getlogin_r) was fixed. And there were architecture + updates across the board (x86, arm, powerpc, cris, h8300, sparc, and mips). + And of course, this release includes the usual pile of bug fixes. Many + thanks for the large number of patches and fixes that were contributed! + +

  + + Unfortunately, this release is not binary compatible with earlier uClibc + releases. As noted as item 3 here, + uClibc does not (yet) attempt to + ensure binary compatibility across releases. We will eventually do that + (once we reach the "1.0" release) but not yet. A few bugs turned up that + needed to be fixed, and the only good way to fix them was to change some + fundamental data structure sizes. As a result, this release is _NOT_ + binary compatible with earlier releases -- you will need to recompile your + applications. The x86, arm, powerpc, and mips architectures (i.e. the + systems Erik has available in his office for testing) have been tested and + are known to work following this change. Other architectures may + need additional updates. Sorry about that, but it had to be done. + +

  + As usual, the + Changelog + and source code + for this release are available here. + You might want to download uClibc from the closest + kernel.org mirror site. + Just pick the closest mirror site, and then go to + + http://www.XX.kernel.org/pub/linux/libs/uclibc/ + to download uClibc, where XX is your two letter country code. +

  + +

  +

• 25 January 2003, dev system updates, arm image released +
  + + A number of additional problems have been fixed and the arm build + is now, finally, compiling and working as expected. As such, + I have updated the + i386 development system image, the + + powerpc development system image, and I am also releasing + upon an unsuspecting world the brand new + + arm development system image! + Have fun! +

  + + All three development system images were compiled and built using the stock + buildroot system. These were also + built using the (about to be announced in a couple on minutes) uClibc + 0.9.17 release, so if you want to begin compiling and testing stuff with + uClibc, but you don't feel like spending the _hours_ it takes to download, + configure, and build your own uClibc based development system -- then you + may want to download these and give them a try. They each contain a 100 MB + ext2 filesystem with everything you need to begin compiling your own + applications. I have (at least minimally) tested each of them and verified + that the included gcc and g++ compilers produce working uClibc linked + executables. + +

  + Oh, and I have also have updated the uClibc/gcc toolchain builders, so + if you just want a simple uClibc/gcc toolchain, + one of these should work for you. +

  + + +

  +

• 10 January 2003, dev system updates, powerpc image released +
  + + A few problems showed up in yesterday's development system release + (adduser was broken, gdb didn't work, libstdc++ shared libs were missing, + etc). So I've updated the + i386 development system image to fix these problems. + Also, the + powerpc development system image has finally finished compiling + and is now released upon an unsuspecting world. Have fun! +

  + + +

  +

• 9 January 2003, uClibc development system released +
  + + CodePoet Consulting (i.e. Erik) has been working hard on buildroot recently, and is pleased to + offer a full stand-alone uClibc-only development system. This is an ext2 + filesystem for i386 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, valgrind, + busybox, GNU coreutils, and more, this should have pretty much everything + you need to get started building your own applications linked against + uClibc. By using a uClibc only system, you can avoid all the painful + cross-configuration problems that have made using uClibc somewhat painful + in the past. A powerpc and an arm version are in progress. Expect them + to be released shortly.... + +

  + + The + uClibc development system is an 18MB bzip2 compressed ext2 filesystem, + so be prepared to wait if you are on a slow link. If you wish to have more + space, you can loop mount it and 'cp -a' the contents to their own + partition, or do what I did... WARNING, the following can be very + dangerous. Please be sure you know what you are doing before trying this. + I am not responsible if you lose all your important data.I had a spare + hard drive (in my case /dev/hdg but you'll want to adapt this to your own + needs), so I partitioned it with a single ext2 partition filling the drive + (in my case /dev/hdg1). Then I ran:

  
  
  
  
  
  
  
  
      +    bzcat root_fs_i386.bz2 | dd of=/dev/hdg1
  
  
  
  
  
  
  
  
      +    e2fsck -f /dev/hdg1
  
  
  
  
  
  
  
  
      +    resize2fs -p /dev/hdg1

  + + which overwrote everything on /dev/hdg with the new uClibc devel system, + and then expanded the filesystem with the uClibc devel system till it + filled the whole drive. +

  + + +

  +

• 8 November 2002, uClibc 0.9.16 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.16. This release adds full support (including a native shared + library loader) for the CRIS architecture, contributed by Tobias Anderberg. + Stefan Allius contributed a number of patches to fix the initialization + order for shared library global constructors and destructors as well as a + large number of SuperH fixes and cleanups. uClibc now compiles with + newer versions of gcc (i.e. RedHat 8.0). Thanks to Christian Michon, + uClibc no longer requires perl to compile. Steven J. Hill fixed dlopen for + mips. Several problems with pty and tty handling were fixed. Manuel Novoa + added new support for an /etc/TZ file to globally set the system timezone, + and fixed up a number of remaining wide char issues. Manuel is still hard + at work on bringing full locale support (optional of course) to uClibc. + And of course, this release includes the usual pile of bug fixes. Many thanks + for the large number of patches and fixes that were contributed! +

  + + Erik and Manuel have been working on a + + document describing some of the differences between uClibc and glibc. + It's not yet 100% complete, and it hasn't been nicely formatted yet. But + it contains a lot of helpful information and is worth a look. +

  + + And finally, the the old uClibc configuration system has been completely + removed (and there was much rejoicing). It was replaced with an entirely + new system based on LinuxKernelConf, + which has since been included into Linux 2.5.45, so it looks like Erik made + the right choice. Of course, those who have existing build systems using uClibc + will need to make a few changes... We think the change is worth it. +

  + As usual, the + Changelog + and source code + for this release are available here. + You might want to download uClibc from the closest + kernel.org mirror site. + Just pick the closest mirror site, and then go to + + http://www.XX.kernel.org/pub/linux/libs/uclibc/ + to download uClibc, where XX is your two letter country code. +

  + Updated gcc-3.2 and gcc-2.95 toolchains will be released shortly. +

  + + +

  +

• 16 September 2002, gcc-3.2 and gcc-2.95 toolchains released +
  + + CodePoet Consulting (i.e. Erik) has released updated gcc-3.2 and gcc-2.95 + uClibc toolchains. These toolchains build real gcc cross compilers (i.e. + not just a wrapper) and create executables linked vs uClibc. The new + gcc-3.2 provides uClibc support with the latest and greatest compiler + available from the gcc team. The gcc-2.95 toolchain has been updated to + the latest version of uClibc and now provides full C++ support, using the + STLport standard C++ library. +

  + + This toolchain should make it easy for anyone to build uClibc based + applications. + Source code can be downloaded here. + Be aware that much of the needed source code will actually be downloaded on + when you compile the toolchains. To build a toolchain, simply + grab the source, edit the Makefile to select where you would like + the toolchain installed, run 'make', and then go watch TV, eat + dinner, or visit with your friends while it compiles. It takes + about 15 minutes for Erik to compile the gcc-3.2 toolchain (w/C++ support) + on his Athlon XP 1600 (not counting the time it takes to download + source code). +

  + + + +

  +

• 27 August 2002, uClibc 0.9.15 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability + of uClibc 0.9.15. This release fixes a number of problems that turned + up since the last release. The good news is that uClibc now + passes all tests in the perl 5.8 and Python 2.2.1 test suites, both with + and without pthreads. So without any further ado.... +

  + The + Changelog + and source code + for this release are available here. +

  + Have fun! +

  + + +

  +

• 12 August 2002, uClibc 0.9.14 Released +
  + + CodePoet Consulting is slightly less pleased then usual to announce the + immediate availability of uClibc 0.9.14. This is, unfortunately, a bugfix + release intended to fix the couple of dumb things that slipped into the + previous release. Version 0.9.13 of uClibc would fail to compile when + enabling both RPC and Pthreads. There was also a problem with RPC thread + local storage (but noone noticed since it didn't compile ;-). Also, the + thread locking in exit(), onexit() and atexit() was broken, and wasn't + actually locking anything. This release also fixes uClibc's gcc wrapper + to use crtbeginS.o and crtendS.o when compiling PIC code, fixing a subtle + bug (that was much less subtle on powerpc). Finally, this release includes a + few minor compile warning cleanups. +

  + The + Changelog + and source code + for this release are available here. +

  + Have fun! +

  + + +

• 12 August 2002, Native uClibc/gcc-3.1.1 toolchain released +
  + + CodePoet Consulting (i.e. Erik) has released an updated native + uClibc/gcc-3.1.1 toolchain. This toolchain builds a real gcc cross + compiler (i.e. not just a wrapper) and creates executables linked vs + uClibc. This toolchain has been (briefly) tested as working on x86, arm, + mips, and arm7tdmi (uClinux). This toolchain provides a number of + improvements over previous releases. In particular, Steven J. Hill found + and fixes a number of "glibc-isms" in the libstdc++ math support which + caused a number of math functions to be mapped to the non-standard named + under GNU libc. This release also includes greatly improved uClinux + "elf2flt" support, and it now produces working flat binaries for my + uClinux/arm7tdmi system. The native uClibc/gcc-2.95 toolchain will be + updated in a few days, and will include STLport which will allow that + toolchain to also provide full C++ support. +

  + + This toolchain should make it easy for anyone to build uClibc based + applications. + Source code can be downloaded here. + Be aware that much of the needed source code will actually be downloaded on + demand when you compile things. To build the toolchain, simply + grab the source, edit the Makefile to select where you would like + the toolchain installed, run 'make', and then go watch TV, eat + dinner, or visit with your friends while it compiles. It takes + about 15 minutes for Erik to compile the gcc-3.1.1 toolchain (w/C++ support) + on his Athlon XP 1600 (not counting the time it takes to download + source code). Your results may vary... +

  + +

• 9 August 2002, uClibc now mirrored on kernel.org! +
  + uClibc is now available from the kernel.org mirrors! This should make + uClibc downloads much faster. The kernel.org mirrors will have all + uClibc release versions (everything but the daily snapshots). + Here is a list of all the kernel.org mirror sites. + Just pick the closest mirror site, and then go to "/pub/linux/libs/uclibc/" + to download uClibc. + Just pick the closest mirror site, and then go to + + http://www.XX.kernel.org/pub/linux/libs/uclibc/ to download the latest + uClibc release from a nice fast system. +

  +

  + +

  +

• 9 August 2002, uClibc 0.9.13 Released +
  + + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.13. After several days of testing, this release is looking very + solid. This release fixes three security vulnerabilites in previous + releases. There was an off-by-one buffer overflow in the group handling + code, and integer overflows in calloc() and xdr_array(). +

  + + This release adds native shared library support for the Hitachi + SuperH architecture, thanks to Stefan Allius and Edie C. Dost. A + new mmap based malloc was implemented by Miles Bader. This is much + smarter than the old "malloc-simple" and is now the default for + mmu-less systems, where it should greatly help reduce memory + fragmentation and wastage. In addition to these larger items, there + has been a lot of work done to make uClibc a cleaner, more + capable, library. Most applications now compile and run without + any trouble. +

  + The + Changelog + and source code + for this release are available here. +

  + Have fun! +

  + + +

• 11 July 2002, Native uClibc toolchains updated +
  + CodePoet Consulting (i.e. Erik) has released updated native + uClibc/gcc-3.1 and uClibc/gcc-2.95 toolchains. These toolchains + build real gcc cross compilers (i.e. not just a wrapper) and create + executables linked vs uClibc. These toolchains have been tested + and found working on x86, arm, and mmu-less arm. They should work + (at least in theory!) for all architectures supported by uClibc. +

  + + These toolchains should make it easy to anyone to build uClibc based + applications. + Source code can be downloaded here. + Be aware that much of the needed source code will actually be downloaded on + demand when you compile things. To build the toolchain, simply + grab the source, edit the Makefile to select where you would like + the toolchain installed, run 'make', and then go watch TV, eat + dinner, or visit with your friends while it compiles. It takes + about 15 minutes for Erik to compile the gcc-3.1 toolchain (w/C++ support) + on his Athlon XP 1600 (not counting the time it takes to download + source code). Your results may vary... +

  + + +

  +

• 20 June 2002, uClibc 0.9.12 Released +
  + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.12. This release adds an i960 port, an initial alpha port, + fully working mips shared library support, shared library support fixes + for on powerpc, and many other improvements. One very exciting new feature + is nearly complete locale support, thanks to a lot of hard work by Manuel + Novoa III. uClibc's locale support is much smaller than glibc's, + though it is also slightly less flexible. This release was delayed by a + month due to the arrival of a new baby at Erik's house. For those that + have been anxiously waiting, this release should certainly be worth the + wait. Have fun! +

  + The Changelog + and source code + for this release are available here. + +

• 28 May 2002, Native uClibc/gcc-3.1 toolchain +
  + CodePoet Consulting has released source code and a Makefile to build a + gcc-3.1 toolchain that natively targets uClibc. Additionally, the + gcc-3.0.4 and gcc-2.95 toolchains have also been updated. These toolchains + make it easy to build uClibc based applications. + Source code can be downloaded here. + and is now much smaller, + since much of the needed binutils and gcc source code is now downloaded on + demand. To build the toolchain, simply grab the source, edit the Makefile + to select where you would like the toolchain installed, and then run 'make' + and wait for it to compile. + +

  +

• 10 April 2002, uClibc 0.9.11 Released +
  + CodePoet Consulting is pleased to announce the immediate availability of + uClibc 0.9.11. This release is primarily focused on fixing the issues that + have turned up since the last release. Several bugs in the gcc wrapper + have been fixed, allowing applications such as iproute2 and XFree86 to link properly. + Large file support has been improved, and a thread locking bug was + fixed that could cause s*printf calls to deadlock when threading was + enabled. Several bugs were also fixed with the powerpc, h8300, m68k, + sparc, and mips architecture support. Many additional applications now + compile and run perfectly and have been added to the working applications list . +

  + The Changelog + and source code + for this release are available here. + + + +

  +

• 10 April 2002, Native uClibc/gcc-3.0.4 toolchain +
  + CodePoet Consulting has released source code and a Makefile + to build a gcc-3.0.4 toolchain that natively targets uClibc. + This brings with it full C++ support for uClibc, including the + libstdc++ library. A gcc-2.95.x toolchain will also be released + shortly, but is not yet ready. At this time, only source code and + a Makefile for the native uClibc toolchain is being released (i.e. + no binaries, sorry). + Source code can be downloaded here. +

  + To build the toolchain, simply grab the source, edit the Makefile + to select where you would like the toolchain installed. Then + run 'make' and wait for it to compile. If you do not have a copy + of uClibc already, it will download the latest daily snapshot. + + +

  +

• 21 March 2002, uClibc 0.9.10 Released! +
  + + CodePoet Consulting is pleased to announce the immediate + availability of uClibc 0.9.10. This release adds pthreads support + (including pthreads support for mmu-less systems!). Additionally, + thanks to Manuel Novoa III, we now have a completely new stdio + library, which is small, standards compliant, supports pthreads, + wide/narrow streams, large files, and can even operate in a + low-memory unbuffered mode. Many, many bugs have been fixed and a + number of additional applications now compile and run perfectly. + Even with all these changes, uClibc continues to be very small. + On x86, a default build of the uClibc C library is still just 168k. + +

  + + To make things more interesting, the release also adds support for + C++ constructors and destructors. To make it easy to use uClibc + when developing C++ applications, this release also provides a + wrapper for the GNU C++ compiler. Of course, for more complex C++ + applications, such as those using iostreams, a standard C++ library + (libstdc++) is required. A native GNU toolchain (binutils/gcc) that + provides libstdc++ linked with uClibc 0.9.10 will be released in the + next couple of days, so stay tuned. + +

  + The Changelog + and Source code + for this release are available here. +

  + + +

  +

• 4 February 2002, uClibc 0.9.9 Released! +
  + + CodePoet Consulting is pleased to announce the immediate + availability of uClibc 0.9.9. With this release, + just about + everything we have tested now compiles and runs. In fact, + there are now so many programs on the working application list that + rather than continue to add to this list, from now on we + will only be adding applications to the not working list. Most applications + on the not working list either require pthreads, or require + wide-character support. Work on wide-character support is + well underway, and will hopefully be moving into CVS in the next week or + two. Full pthreads support and rentrancy are on the TODO list + and are expected to be complete in the next couple of months. +

  + The Changelog + and Source code + for this release are available here. +

  + One final bit on news -- as some of you may have noticed, uclibc.org + has been a bit overloaded and somewhat slow recently. The server should + be getting colocated tomorrow, which will eliminate the speed problem. + During the move, there may be some temporary disruption of service... +

  + Have Fun! + +

  +

• 22 December 2001, uClibc 0.9.8 Released! +
  + + After many months of initial development, we are pleased to announce the + release of uClibc 0.9.8. This release should be quite solid, and is very + usable. This also, hopefully, marks a transition from a slow incubation + phase to a more methodical release cycle. From now one, there should be + approximately one release per month. +

  + The source code for this release is available + here. + + +

  +

• 26 November 2001, powerpc shared libraries fully working +
  + Dave Schleef finished off the the work needed for shared library support on + powerpc. There had been a few problems remaining, and those are now squashed. + So shared libs on powerpc should be working fully now. + +

  +

• 14 November 2001, m68 compiles again, Large file support working +
  + About a month ago I synced the header files with glibc 2.2.4 for better + C++ support and better standards compliance. I forgot to sync up m68k, + sparc, powerpc, and mipsel. Dave Schleef fixed powerpc while he was fixing + up the shared lib loader. I just fixed up m68k, sparc, and mipsel so they + should all compile again. +

  + I also finished up fixing large file support (just enable DOLFS in your + Config file to enable it) and it is working just great, and greatly increases + the number of glibc applications that will work "out-of-the-tarball" without + needing any changes. + + +

• 12 November 2001, powerpc shared lib support +
  + Thanks to David Schleef, uClibc now has full shared library support + on powerpc. This brings full shared library support to x86, ARM, and + now powerpc. Thanks Dave! + + +

  +

• 7 November 2001, uClibc application list +
  + uClibc now has a list of applications + that are known to work. If you have any applications to add to the + list, submissions are welcome! + + +

  +

• 18 October 2001, buildroot uClibc example system +
  + + Those wanting an easy way to test out uClibc and give it + a test drive can download and compile + buildroot. + This is a nifty buildsystem that will automagically download and build + a User-Mode Linux + kernel, and will then download source for and compile up a fully + working uClibc based root filesystem. This should make it easy for + people to create their own projects. I hope that this build system + will allow people to more easily use and build uClibc based systems. + As an example of how nicely this works, the + Tuxscreen Project is using a + slightly adjusted variant of the buildroot system to cross + compile the blob bootloader, linux kernel, and a uClibc based jffs2 + root filesystem (busybox, tinylogin, udhcp, lrzsz, pcmcia-cs and + microwindows) for ARM. Pretty cool. + + + +

  +

• 11 October 2001, v850 architecture support +
  + + Miles Bader has contributed support for the v850 architecture. + + +

  +

• 25 Spetember 2001, header files updated +
  + + uClibc's header files are now in sync with glibc 2.2.4, + allowing better standards compliance, better portibility, and + better C++ support. + +

  +

• 4 July 2001, ARM shared library support +
  + + uClibc now has full shared library support on ARM. + + +

  +

• 9 May 2001, libm added +
  + + uClibc now has a very complete math library. + + +

  +

• 9 May 2001, ld.so added +
  + + uClibc now has a native ld.so. It currently is only ported to work on x86, + but porting to other architectures should not be too difficult. + + +

• 15 March 2001, powerpc port added +
  + + David Schleef contributed a powerpc port, which is now in CVS. + +

• 19 February 2001, SH port added +
  + + Jean-Yves Avenard contributed an SH port. See his email + with the initial patch here. + +

• 16 January 2001, uClibc as a shared library +
  + + As if January 16, uClibc can now be used (at least on x86) as a shared + library. See the email + announcing this achievement. + +

• 11 January 2001, gcc wrapper added +
  + + Manuel Novoa III has created a wrapper for gcc that makes compiling apps vs uClibc + as simple as just setting "CC" to gcc-uClibc-< arch>. This even works when cross + compiling! Very cool. + +

• 3 January 2001, uClibc now has a web page +
  + + A lot of work has been going on under the hood with uClibc, + so I decided to put together this webpage to let the world know + that it exists and is getting to be usable. + +

+ + + + Index: cvs_howto.html =================================================================== --- cvs_howto.html (nonexistent) +++ cvs_howto.html (revision 1765) @@ -0,0 +1,44 @@ + + + +

How to use CVS

+ + +If you want to know all the gory details, you will want to visit +the CVS main web page.

+For the impatient, the following is probably about all you need to know: +

+ +

+

cvs checkout -c

+

Will list the modules available for checkout +

cvs checkout < module name >

+

Will checkout the named module +

cvs co < module name >

+

Same thing +

cvs update

+ +

Updates your local archive so it is in sync with the repository + -- your local updates are left intact. Tries to merge upstream updates + into your local updates. You will see the following tags when it is + updating your local repository: C means conflict, U means update, + P means patched, and M means modified. +

cvs up

+

Same thing +

cvs update < file name >

+

Same thing but for just the named file(s)/directory(s). +

cvs commit

+

Will check in all your work. +

cvs add < file name >

+ +

Adds the named file/directory into CVS +

cvs remove < file name >

+

Removes the named file/directory from the upstream repository. +

cvs rm < file name >

+

Same thing +

cvs log < file name >

+

+ + + +