This is the mail archive of the
mailing list for the glibc project.
Re: newbie trying to compile libc 2.9 latest
On Wed, Feb 4, 2009 at 4:53 PM, Nix <firstname.lastname@example.org> wrote:
> On 4 Feb 2009, Justin Mattock verbalised:
>> /mnt/glib/glibc-build/libc_pic.os: In function `__libc_fork':
>> undefined reference to `__sync_bool_compare_and_swap_4'
> This is all for the same reason: glibc doesn't know what CPU you've got,
> so doesn't know what atomic operations to provide. You called configure
>> here is my command line:
>> sudo /mnt/glib/glibc-20090202/configure --prefix=/usr
>> CC=/usr/local/bin/i686-pc-linux-gnu-gcc-4.4.0 --enable-add-ons
>> (I know I need more, but not sure what to use);
I was using ../configure --prefix=/usr --enable-add-ons
> You *always* have to provide at least a --build argument, e.g.
> --build=i686-pc-linux-gnu. The default is i386-pc-linux-gnu, which is
> too old to build NPTL.
be good for a macbook pro?
> The rest of the configure flags are a matter of taste: personally, last
> time I built glibc, I built with --prefix=/usr --enable-shared
> --enable-profile --disable-bounded --enable-bind-now
> --enable-add-ons=nptl,libidn --enable-kernel=2.6.27
Will libc work properly without the shared libs?
trying(for personal use) to build something lightweight.
> (Why are you sudoing configure? Never, never, never configure or compile
> things as root! If you can avoid it, don't even install things as root:
> use fakeroot or something similar instead. But compilation, no, no,
> compilers are far too complex beasts to trust with root privileges.)
This is weired to me i.g. I compiled
gcc-core with /usr/local/bin/make
and it compiled up to towards the end
(something about permissions denied with bash);
but when compiling the same in libc
I get permissions denied.
(keep in mind my brain is fried at the moment
from compiling, so I'll have to try again later on);
>> I'm using a livecd(ubuntu intrepid)
>> and then mounting /dev/sda1 to /mnt
>> which will be used for a new system(libc is for the new system);
> Run 'make check' and inspect every failure to make sure that it's one
> you can live with (e.g. math/test-ildoubl fails on x86-32 and has for
> years, but it's a tiny least-significant-bit failure that you can
> probably ignore). ('make check' stops every time it hits a failure: run
> it again after inspecting that failure and seeing if you're happy with
> it. Eventually it will complete without error.)
This is one of the reason why I'm compiling libc from the source
(want to make sure everything is specified to the hardware);
> Take care not to overwrite your existing glibc when installing. Install
> somewhere else via 'make install install_root=/installation/location'.
> (If you wanted to replace your existing glibc on a handbuilt system,
> you'd have to whip something up to atomically move the new glibc's lib/
> directory into the real /lib, so that at no time do /lib/ld-linux.so.2
> and /lib/libc.so.6 point to different versions of glibc. In practice,
> moving the glibc lib/ subdirectory into a newly-created subdirectory of
> /lib on the root filesystem and then a mv * into /lib does the trick
> unless you have a very badly-timed power failure.)
As of now the hard drive is pretty much empty
except for a tree that I created, and dev using MAKEDEV.
main concern is once compiling and then installing telling
make to use /mnt/* as the new root tree.
as well as the kernel and all other main programs.
(this way I don't have /mnt/lib/modules/);
Thanks for the info.
Justin P. Mattock