playing at long last with uClibc++

Rob Landley rob at landley.net
Sat Nov 1 09:30:48 UTC 2008


On Saturday 01 November 2008 02:54:14 Christian MICHON wrote:
> On Sat, Nov 1, 2008 at 8:01 AM, Rob Landley <rob at landley.net> wrote:
> > On Friday 31 October 2008 08:07:41 Christian MICHON wrote:
> >> Hi,
> >>
> >> I *finally* managed to compile uclibc++ and it now complains about
> >> powl, sqrtl, etc... missing on my system.
> >> I'm still using uclibc-0.9.29 :(
> >
> > I've been fighting with that sucker all week.
>
> well, it almost took me a year since I tried it first :)

*shrug*  I could beat compilation out of it by hand, but I'd like something 
that has at least a minimal chance of working in future gcc versions...


> > I suppose I can just disable IMPORT_LIBSUP in uClibc++ defconfig, but
> > then the result seems unlikely to work.  (Not that I'm any sort of expert
> > on what C++ needs, I avoid it as much as possible...)
> >
> > Rob
>
> what I usually do is to build both gcc-core and gcc-g++ at the same
> time (same directory).

There's another way to do it?  (That's what it's doing, following Linux From 
Scratch's advice.)  It works fine as a host build, and it works find 
building "all-gcc" instead of "all" (which builds g++, builds libgcc_eh.a, 
but doesn't build libstdc++ or libsupc++).  Unfortunately, attempting to 
cross compiling libstdc++ makes it freak out, and uClibc++ depends on 
libsupc++ which you don't get if you don't build libstdc++.

> I do also a bootstrap of gcc at the same time. In the end, libstdc++
> is compiled.

I take it you're building it natively, not cross compiling it for a target?

Possibly I could just build a native C compiler and then add C++ support to it 
after the fact, building natively.

I also need to look at Cross Linux From Scratch in the morning, and see what 
it says to do.  (Admittedly vs glibc instead of vs uclibc, but it's usually 
got some good info...)

> when doing so with uclibc, you usually get an error after long minutes
> of compilation.

I noticed this.

> the solution I found last year (before I released c++ with D*B) was:
> > when compiling g++, it usually ends up using a soft link to
> > liststdc++/config/os/gnu-linux/ctype_noninline.h what I did was to
> > replace this file, too glibc dependent, by this one:
> > liststdc++/config/os/generic/ctype_noninline.h
> > and it finally worked
>
> what I have not tried yet is to compile uClibc++ with g++ but without
> libstdc++. (I'll try that tonight, in > than 12h)

Interesting.  If you notice the error I quoted last time, it was failing to 
find "gcc-core/libstdc++-v3/../gcc/gthr-.h" which is a file that doesn't 
exist.  There's a bunch of gcc/gthr-*.h files, but the * part is getting 
dropped out by the ./configure or make infrastructure.  (Because the gcc 
build is constructed entirely out of nuclear waste.)

This might be easier to beat sense out of if I move to gcc 4.3, but then the 
problem moves to getting arm soft float to work.  (I have notes from Peter 
Mazinger on how to go about it, but it's another big fiddly job.  I dislike 
replacing one big fiddly problem with another big fiddly problem, it's not 
necessarily progress.)

Rob



More information about the uClibc mailing list