On Saturday 01 November 2008 06:29:50 David McCullough wrote: > > 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++).
Yeah, that's another way to do it. Build a totally unrelated version, copy the library out, and then do a fresh compilation of what you actually want. I'm trying to avoid needing to do that, but that's the only code path that ever seems to get any testing upstream... > 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++. I never build glibc for the target. (Not only is glibc an extra package my base self-bootstrapping system image doesn't need, but it would require adding perl to build glibc.) I can always just add c++ support as a native build, but I've already got _most_ of a native c++ building during the root filesystem creation stage. And uClibc++ is quite happy building, it just needs this one darn .a file that gcc won't deign to compile if you haven't mastered the secret handshake and gone through the full initiation ritual where they award you your silly hat... > libsupc++ works fine with them both. We do build our toolchain with the > static libgcc option to make cross/targetting easier. My cross toolchain is --disable-shared, but that doesn't support c++ either. This is the native toolchain to install in the target root filesystem, which I'm trying to create via cross compiling so I have something to boot I can build more stuff in... > 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'm assuing that uClibc++ already has all the c++ headers it needs, and if not that it's a uClibc++ issue Garrett can fix if I ask him nicely. > I don't recall any special magic, Your special magic is building against glibc. > 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 :-( *shrug* Thing break for me all the time, this is by no means the nastiest or hairiest issue I've had to deal with. It's just the current one. :) > Cheers, > Davidm Thanks, Rob _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
