OSDN Git Service

add an entry about gnu malloc compat option
[uclinux-h8/uClibc.git] / docs / uclibc.org / FAQ.html
index 1ce1229..d129089 100644 (file)
@@ -24,6 +24,10 @@ have additions to this FAQ document, we would love to add them,
 <li><a href="#wrapper">What happened to the old toolchain wrapper?</a>
 <li><a href="#dev_systems">Is a pre-compiled uClibc development system available?</a>
 <li><a href="#bugs">I think I found a bug in uClibc!  What should I do?!</a>
+<li><a href="#miscompile">My package builds fine but link fails with errors like "undefined reference 
+       to __fputc_unlocked", who do I blame?!</a>
+<li><a href="#gnu_malloc">My package builds fine but link fails with errors like "undefined reference
+       to rpl_realloc / rpl_malloc", who do I blame?!</a>
 <li><a href="#job_control">Why do I keep getting "sh: can't access tty; job control
        turned off" errors?  Why doesn't Control-C work within my shell?</a>
 <li><a href="#autoconf">How do I make autoconf and automake behave?</a>
@@ -227,14 +231,34 @@ How could it be smaller and not suck?</a></h2>
     You will need to have your own uClibc toolchain.  A toolchain consists
     of <a href="http://sources.redhat.com/binutils/">GNU binutils</a>,
     <a href="http://gcc.gnu.org/">the gcc compiler</a>, and uClibc, all
-    built to produce binaries linked with uClibc for your target system.
-    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>.
-    Simply adjust the Makefile settings to match your target system,
-    and then run 'make'.
+    built to produce binaries for your target system linked with uClibc.
+    You can build your own native uClibc toolchain using the
+    <a href="http://buildroot.uclibc.org/">uClibc buildroot system</a>.
+
+    <p>
+    To build your own uClibc toolchain, follow the following simple
+    steps:
+    <ul>
+       <li> Point your web browser <a href="http://buildroot.uclibc.org/">here</a>,
+       <li> Download of copy of buildroot
+       <li> Unpack the tarball on your Linux system somewhere
+       <li> Edit the Makefile as needed if you wish to change anything.
+       <li> run 'unset CC'.   Then run 'unset CXX'.  Some Linux systems
+           (i.e. Gentoo) set variables such as 'CC' in the system environment
+           which really messes things up when cross compiling.
+       <li> run 'make menuconfig'
+       <li> Select the things you want to build.  If you <em>only</em> want a
+           toolchain, leave everything except the toolchain disabled.
+       <li> save your buildroot configuration.
+       <li> run 'make'
+       <li> go eat a nice wholesome sandwich, drink a pop, call a friend,
+           play a video game, and generally find something to do.  While you
+           are waiting, buildroot will download all the needed source code and
+           then compile things up for you.
+       <li> You should now have a shiny new toolchain, and maybe even a shiny
+           new uClibc based root filesystem or development system, depending on
+           the options you selected.
+    </ul>
 
 <hr />
 <p>
@@ -244,13 +268,17 @@ How could it be smaller and not suck?</a></h2>
     Yes, you really do need to build a toolchain to produce uClibc binaries.
     We used to provide a toolchain wrapper, but that has been removed due to
     numerous problems.  The uClibc developers have gone to a lot of trouble
-    to produce a
-    <a href="/cgi-bin/cvsweb/toolchain/">uClibc toolchain builder</a>,
-    and the
-    <a href="/cgi-bin/cvsweb/buildroot/">uClibc buildroot system</a>,
-    which make it easy to build your own uClibc toolchain.  Feel free to take
-    the gcc and binutils patches we provide and use them in your own toolchain
-    build system.
+    to produce the
+    <a href="http://buildroot.uclibc.org/">uClibc buildroot system</a>,
+    which makes it easy to build your own uClibc toolchain and/or an initial
+    uClibc based system.
+
+    <p>
+    Feel free to take the gcc and binutils patches we provide and use them in
+    your own toolchain build system.  If you choose to use your own toolchain
+    build system, you will need to use these patches since the upstream GNU
+    binutils and gcc releases do not currently have full support for building a
+    uClibc toolchain.
 
 
 <hr />
@@ -261,12 +289,18 @@ How could it be smaller and not suck?</a></h2>
     It is possible in some limited cases to re-use an existing glibc toolchain
     and subvert it into building uClibc binaries by using gcc commands such as
     "-nostdlib" and "-nostdinc".   In fact, this used to be the recommended
-    method for compiling programs with uClibc using a uClibc toolchain wrapper.
+    method for compiling programs with uClibc, and we made this easy to do by
+    providing a uClibc toolchain wrapper, which attempted to automagically subvert
+    an existing glibc toolchain.
+
+    <p>
+
     This toolchain wrapper was removed from uClibc 0.9.22, and it will not be
-    coming back.  This is because it is impossible to fully subvert an existing
-    toolchain in many cases.  As uClibc has become more capable the many problems
-    with re-using an existing glibc toolchain led us to conclude that the only
-    safe and sane way to build uClibc binaries is to use a uClibc toolchain.
+    coming back.  This is because it proved impossible to completely subvert an
+    existing toolchain in many cases, and therefore proved to be a real
+    maintainence burder.  As uClibc became more capable, the many problems with
+    re-using an existing glibc toolchain led us to conclude that the only safe
+    and sane way to build uClibc binaries was to use a uClibc toolchain.
 
     <p>
 
@@ -280,41 +314,50 @@ How could it be smaller and not suck?</a></h2>
 <h2><a name="dev_systems">Is a pre-compiled uClibc development system available?</a></h2>
 <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
-    grab a copy of the uClibc development systems, currently available for
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_i386.bz2">i386</a>,
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_powerpc.bz2">powerpc</a>,
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_arm.bz2">arm</a>,
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_mips.bz2">mips</a>,
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_mipsel.bz2">mipsel</a>, and
-    <a href="http://www.kernel.org/pub/linux/libs/uclibc/root_fs_sh4.bz2">sh4</a>.
-    The powerpc dev system mostly works, but there is still some sortof
-    problem with the shared library loader that has not yet been resolved.
+    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 grab a
+    pre-compiled uClibc development system.  These are currently available for
+
+    <a href="http://www.uclibc.org/downloads/root_fs_arm.ext2.bz2">arm</a>,
+    <a href="http://www.uclibc.org/downloads/root_fs_armeb.ext2.bz2">armeb</a>,
+    <a href="http://www.uclibc.org/downloads/root_fs_i386.ext2.bz2">i386</a>,
+    <a href="http://www.uclibc.org/downloads/root_fs_mips.ext2.bz2">mips</a>,
+    <a href="http://www.uclibc.org/downloads/root_fs_mipsel.ext2.bz2">mipsel</a>,
+    <a href="http://www.uclibc.org/downloads/root_fs_powerpc.ext2.bz2">powerpc</a>, and
+    <a href="http://www.uclibc.org/downloads/root_fs_sh4.ext2.bz2">sh4</a>.
+
+    <p>
+
+    These are bzip2 compressed ext2 filesystems containing all the development
+    software you need to build your own uClibc applications, including: bash, awk,
+    make, gcc, g++, autoconf, automake, ncurses, zlib, openssl, openssh, gdb,
+    strace, busybox, GNU coreutils, GNU tar, GNU grep, etc.
 
     <p>
-    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 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.
+
+    Each of these uClibc development systems was created using
+    <a href="http://buildroot.uclibc.org/">buildroot</a>, specifically,
+    <a href="http://www.uclibc.org/downloads/buildroot.tar.bz2">buildroot.tar.bz2</a>
+    along with <a href="http://www.uclibc.org/downloads/buildroot-sources">these sources</a>.
+
+    <p>
+
+    These development systems should provide pretty much everything you need to get
+    started building your own applications with uClibc.  Once you download one of
+    these systems, you can then boot into it, loop mount it, dd it to a spare drive
+    and use a tool such as resize2fs to make it fill a partition...  Whatever works
+    best for you.
 
     <p>
     The quickest way to get started using a root_fs image (using the i386
     platform as an example) is:
     <ul>
-    <li>Download root_fs_i386.bz2 from kernel.org</li>
-    <li>bunzip2 root_fs_i386.bz2</li>
-    <li>mkdir root_fs</li>
-    <li>su root</li>
-    <li>mount -o loop root_fs_i386 root_fs</li>
-    <li>chroot root_fs /bin/sh</li>
+       <li>Download root_fs_i386.bz2 from uclibc.org</li>
+       <li>bunzip2 root_fs_i386.bz2</li>
+       <li>mkdir root_fs</li>
+       <li>su root</li>
+       <li>mount -o loop root_fs_i386 root_fs</li>
+       <li>chroot root_fs /bin/su -</li>
     </ul>
     Type "exit" to end the chroot session and return to the host system.
     <p>
@@ -327,10 +370,11 @@ How could it be smaller and not suck?</a></h2>
 <p>
 
     If you find a problem with uClibc, please submit a detailed bug report to
-    the uClibc mailing list at uclibc@mail.uclibc.org.  Please do not send
-    private email to Erik asking for private help unless you are planning on
-    paying for consulting services.
-
+    the uClibc mailing list at <a href="mailto:uclibc@mail.uclibc.org">
+    uclibc@mail.uclibc.org</a>.  Please do not send private email to Erik
+    (the maintainer of uClibc) asking for private help unless you are planning
+    on paying for consulting services.  When we answer questions on the uClibc
+    mailing list, it helps everyone, while private answers help only you...
 
     A well-written bug report should include an example that demonstrates the
     problem behaviors and enables anyone else to duplicate the bug on their own
@@ -339,6 +383,39 @@ How could it be smaller and not suck?</a></h2>
     strace, ltrace, and or valgrind to create a logfile showing the problem
     behavior.
 
+
+<hr />
+<p>
+<h2><a name="miscompile">My package builds fine but link fails with errors like 
+       "undefined reference to __fputc_unlocked", who do I blame?!</h2>
+<p>
+
+    This error crops up when a build system mixes system headers (say glibc) 
+    with the target headers (say uClibc).  Make sure your build system is not 
+    including extraneous include options (-I) and double check that it is using 
+    the correct compiler.  Many build systems incorrectly force things like 
+    -I/usr/include or -I/usr/local/include or -I${prefix}/include (which usually 
+    just expands to -I/usr/include).
+
+
+<hr />
+<p>
+<h2><a name="gnu_malloc">My package builds fine but link fails with errors like "undefined reference
+       to rpl_realloc / rpl_malloc", who do I blame?!</h2>
+<p>
+
+    This error crops up because you didn't enable MALLOC_GLIBC_COMPAT support.
+    Configure scripts detect whether your libc supports "GNU malloc" features by
+    seeing whether malloc(0) returns NULL (glibc malloc(0) will return a non NULL
+    pointer).  uClibc defaults to malloc(0) returning NULL so autoconf will assume
+    malloc from your libc sucks and procede to try and compile the malloc replacement
+    version in the gnulib addon.  However, since not many packages include gnulib,
+    they will fail to link with rpl_realloc / rpl_malloc errors.  You could force
+    configure to assume working behavior by exporting the variables 'jm_cv_func_working_malloc'
+    (older autoconf) and 'ac_cv_func_malloc_0_nonnull' (newer autoconf) to 'yes'
+    before running `./configure`.
+
+
 <hr />
 <p>
 <h2><a name="job_control">Why do I keep getting "sh: can't access tty; job control
@@ -402,7 +479,7 @@ How could it be smaller and not suck?</a></h2>
      <a href="http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html">
     http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap08.html</a>
     for details on valid settings of TZ.  For some additional examples, read
-    <a href="http://www.uclibc.org/lists/uclibc/2002-August/006261.html">
+    <a href="http://www.uclibc.org/lists/uclibc/2002-August/004010.html">
     http://www.uclibc.org/lists/uclibc/2002-August/004010.html</a> in the uClibc
     mailing list archive.
     You can store the value of TZ in the file '/etc/TZ' and uClibc will then