On Wednesday 11 February 2009 11:29:56 Carmelo AMOROSO wrote: > Folks, > following previous emails I've looked at this issue better, not it's > clearer to me and I'd like to discuss to figure out the best solution. > > I've always used libstdc++ library from gcc toolchain (4.24.) with > uclibc specific pacthes taken from buildroot repository, > (http://sources.uclibc.org/index.py/trunk/buildroot/toolchain/gcc/4.2.4/) > with LOCALE enabled. > > If we look at the files > gcc/libstdc++-v3/config/locale/uclibc/monetary_members.cc > and > gcc/libstdc++-v3/config/locale/uclibc/numeric_members.cc > > (http://sources.uclibc.org/index.py/trunk/buildroot/toolchain/gcc/4.2.4/200 >-uclibc-locale.patch?revision=22318&view=markup) > > we can see the following lines: > > +#define _LIBC > +#include <locale> > +#undef _LIBC > +#include <bits/c++locale_internal.h> > > By explicitly defining _LIBC before including locale.h (and then > bits/uClibc_locale.h) it wants to make some internal definitions visible. > > Indeed in bits/uClibc_locale.h there are symbols (i.e. __global_locale) > and some data structure definition (i.e. __uclibc_locale_struct) within > #ifdef _LIBC just for internal use. > > Now that unifdef tool has been fixed, while building libstdc++ against > sanitised uclibc headers all of these internal symbols have disappeared > (physically deleted from the header) so defining _LIBC will not work any > more. > > I can see three different solutions > > 1) remove the #ifdef _LIBC from within bits/uClibc_locale.h > or > 2)if possible, we should not sanitise this header > or > 3) change #ifdef _LIBC to something different (i.e. _LIBSTDCPP) > and change the libstdc++ to explicitly set this new macro before > including <locale> > > 3) it's almost identical to 1) and requires another extra change > > What do you guys think about ?
Build uClibc++? Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
