playing at long last with uClibc++

[David McCullough]

Jivin Rob Landley lays it down ...
> 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.)

Hmm,  I use a system here that builds (cross) uClibc/uClibc++ without
any problems.

We use a glibc targetted toolchain (full c/c++) so we get all the the
right bits built (including libsupc++).

Then we just use the uClinux-dist wrapper and build everything against
uClibc and either uClibc++ or STLport depending on what we need from C++.
libsupc++ works fine with them both.  We do build our toolchain with the
static libgcc option to make cross/targetting easier.  That way we do not need
to copy anything from the compiler to the target.  We also link some
compiler headers into the cross build include dir for various "bits" dirs
etc needed for c++. A current dist would have all the uClibc/STLport
bits included ready to go.

I don't recall any special magic,  but I can check diffs against uClibc++ if
it sounds like it will help.  We've had this quite a while now,  so the
versions in use may be a little old :-(

Cheers,
Davidm

-- 
David McCullough,  david_mccullough at securecomputing.com,   Ph:+61 734352815
Secure Computing - SnapGear  http://www.uCdot.org   http://www.snapgear.com