On Sat, Nov 1, 2008 at 10:51 PM, Rob Landley <[EMAIL PROTECTED]> wrote: >> The only use of libsupc++.a is apparently to extract some objects from it >> only. > > Er, yes, I said: > >> All I really _need_ is a half-dozen .o files bundled into that .a file,
I did not realize I was that redundant :) > Hence: > >> *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 did not understand the "beat compilation" sentence, but now it makes perfect sense :) > Speaking of which, how's e release going? (Are the stars right?) We're in November here now, right ? > > The fundamental problem is that the gcc build is very non-orthogonal. > > If I can cd into the libsupc++ directory and get it to build just that, I'll > probably be happy with that. (It's a separate directory, it has its own > makefile. Logically this would imply _some_ kind of separation from the rest > of the build. But logic and the gcc build process seem to have very little > in common so far, other than perhaps a distant ancestral relationship...) I'm performing the same trick I did last year, this time outputting a few log file on how libsupc++ was compiled with uclibc-0.9.29. So I'll know shortly if this is doable. > > Writing my own makefile that feeds in the appropriate hand-generated .config > stuff sounds like a maintenance nightmare. reminds me my 2 liner patch to remove ncurses dependency for uclibc compilation... provided I feed a good .config :) > >> thoughts, comments ? at least, I'll try that myself on a native system >> tonight... :) > > Let me know how it goes... baking now... -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
