[uClibc] Fail to build libstdc++v3 against uClibc w/ xlocale

Carl Miller chaz at energoncube.net
Thu Dec 18 19:23:24 UTC 2003


> > If uClibc is configured for extended locale support (__UCLIBC_HAS_XLOCALE__),
> > recent gcc can't build libstdc++v3.  It will complain about __ctype_b,
> > __ctype_toupper, and __ctype_tolower not being defined.  This is because
> > uClibc is reporting itself as GLIBC_2.2 API, which has those three symbols.
> > However, with extended locale support, those three symbols disappear, and
> > are instead replaced by __ctype_b_loc, __ctype_toupper_loc, and
> > __ctype_tolower_loc.  This is consistent with the GLIBC_2.3 API.  Solution:
> > if extended locale support is enabled, report GLIBC_2.3 API, otherwise
> > report GLIBC_2.2 API.  This allows libstdc++v3 to build properly against
> > a uClibc configured either way.
> 
> There are still issues which require patching to libstdc++.  Even the
> current buildroot is incomplete.  But I haven't fixed it because I'm
> continuing to rework the uClibc locale support.  Once the internal
> interface stablizes, I'll look at libstdc++ again and decide whether
> or not to patch the current locale support routines or provide adapted
> routines in a seperate directory.  I'm leaning towards the latter so
> as to avoid future problems resulting from glibc internal changes.

Well, I worked up a full patch set to send off to the crosstool maintainer.
Perhaps the buildroot people would be interested as well.  As I said, I
managed to make a working g++ that links target executables against uClibc
and gcc's libstdc++v3.  I used binutils-2.14.90.0.5 and gcc-3.3.2 with the
attached two patches.

Side note: the largest problem I had with buildroot (that caused me to look
elsewhere and decide on crosstool instead) was that it patched my binutils
and gcc sources in a way that made them incompatible with non-uClibc builds.
IMHO, this is a big no-no.  The attached patches make binutils and gcc
recognize *-*-linux-uclibc as a valid target tuple, and all the uClibc-
specific stuff is conditionaled on such a target being specified.  Thus you
can build uClibc, glibc, and proprietary library tools from one common set
of sources.  I think this is a much cleaner way to go, and in fact, might
be accepted by the FSF into the main binutils and gcc trees with a little
coaxing.  If you feel this is a worthy goal, by all means, go ahead and
submit my patches to the FSF.


                               -----Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: binutils-uclibc.patch.gz
Type: application/octet-stream
Size: 1961 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20031218/6b3bdb25/attachment.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gcc-uclibc.patch.gz
Type: application/octet-stream
Size: 9432 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20031218/6b3bdb25/attachment-0001.obj 


More information about the uClibc mailing list