[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