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