Retiring from uClibc development

Peter S. Mazinger ps.m at gmx.net
Fri Mar 31 09:27:54 UTC 2006


On Thu, 30 Mar 2006, Manuel Novoa III wrote:

> Peter,
> 
> On Thu, Mar 30, 2006 at 10:30:44AM +0200, Peter S. Mazinger wrote:
> > On Wed, 29 Mar 2006, Manuel Novoa III wrote:
> > 
> > If you consider locales defective/not working correctly, removing support 
> > for them would get rid of much of (at least for me, "untouchable") code.
> 
> Wish I knew what your definition of "untouchable" was.  Anyway, the

Generally I considered everything "untouchable" what you wrote, because 
you haven't agreed to split up code into small .c files, rather keep 
them in a big one and using -DL_x to get the part of it (those that were 
MSRC). This has gotten into conflict while I was trying to get IMA 
compile working. Even if IMA compiling is not an option on slow boxes, it 
learned me how many conflicts were present in uClibc, because IMA does not 
accept 2 different uses of the same function (uClibc was full of it, 
either prototype mismatch with the function or 2 different uses, this was 
the motivation to add everywhere the proper headers that were missing, 
you can check a diff to .28 to see this). Currently this MSRC conflict is 
solved by creating a .c that has '#define L_x\n#include some.c' (less 
strings) where I did almost all the splitting and made you angry.

Untouchable in the current context is all the code that has macro calling 
another macro that is calling another and another (up to 5 times), so that 
it became unreadable (at least for me), seen this when I wanted to find an 
offending function that produces a jump relocation and had to query all 
the objects to find the real offenders.
I haven't found a way to simplify these.

> locale support was a proof-of-concept.  While I would like to see it
> rewritten, that doesn't mean we should rip it out.  I know that there
> are people using it.
> 
> > How do you feel then about internals changing to use UTF8 exclusively, 
> > getting rid of the TABLES*/CTYPE*/WCHAR and such config options?
> 
> Why?  The whole point is to provide options.  The majority of devices
> runing uClibc are not desktop systems with lots of ram.  Sometimes
> every little bit helps.

Yes, as does the hiding of internally used functions that save 10% by itself.

> > > > don't want to touch them w/o first asking, but you do not answer. What is 
> > > 
> > > If you're asking about anything related to newer toolchains I'm not using,
> > > issues resulting from your hidden symbol support changes, or from the IMA
> > > compilation stuff, the general answer is "I'm not  currently using that it."

IMA state: it is good for libcrypt/libutil/libm, but not for libc and 
impossible for full libpthread* (libpthread can be done partly)

> > see for ex. buildroot/toolchain/gcc/4.2.0/203*, that is wide character 
> > related as well, not only locales and is related to all gcc versions used 
> > (the oldest checked is 3.3.5, probably all 3.3.x)
> 
> I need to build a new 3.3.6-based toolchain this weekend.  I'll look at
> it then... along with a number of other patches that I spent last
> weekend collecting.  I'm not the only one who hasn't been maintaining
> the toolchains in buildrooot...

Consider then the option to copy os/gnu-linux to os/uclibc resp. 
config/gnu to config/uclibc and patch those, maybe also doing following 
"hack" in c++locale_internal.h that would minimize the impact on the 
rest of the files (after applying 4.2.0 203* patch as well)

#ifdef __UCLIBC_HAS_XLOCALE__
# undef __GLIBC_MINOR__
# define __GLIBC_MINOR__ 3
#endif


in c_locale.h (these will be runtime visible)

#ifdef __UCLIBC__
# define _GLIBCXX_NUM_CATEGORIES 0
//# undef _GLIBCXX_C_LOCALE_GNU /* used only in ctype_noninline.h */
#else
# define _GLIBCXX_NUM_CATEGORIES 6
# define _GLIBCXX_C_LOCALE_GNU 1
#endif

I am not sure if it makes sense to lie about C_LOCALE_GNU, if at all, then 
only if XLOCALE is enabled.

The gettext awareness stuff could also go into this file.

gcc internal guards for some headers (checked in gcc-4.1 and svn), the 
gcc-3 series could have s/_GLIBCXX/_GLIBCPP/ (see 4.2.0 205*):

wchar.h _GLIBCXX_USE_WCHAR_T (instead of __UCLIBC_HAS_WCHAR__) / _GLIBCPP_USE_WCHAR_T
libintl.h HAVE_LIBINTL_H (instead of __UCLIBC_HAS_GETTEXT_AWARENESS__) / seems not to be visible in libstdc++ for gcc-3
iconv.h _GLIBCXX_USE_ICONV (instead of __UCLIBC_HAS_LOCALE__) / HAVE_ICONV

Using those guards would make it acceptable even upstream (applied to 
os/gnu-linux | config/gnu versions)

A big request: if you somehow could get rid of
#define _LIBC
#include <locale>
#undef _LIBC

needed for __global_locale. libstdc++ is an external library and even Erik 
agreed that __x is not to be exported from libc.

Another change added upstream that is a benefit for uClibc due to 
DO_C99_MATH being an option (see the 4.1.0 backport I have sent you) is 
the removal of hardcoded supported math functions replaced by a detection.
Currently the 200* patch requires to have DO_C99_MATH enabled else it 
is misleading what is in libm and what not (but does not enable the newly 
added functions)

Another general gcc issue:
_GLIBCXX_USE_C99 (for gcc-3 s/CXX/CPP/)
upstream disabled for uClibc the general support of C99 within gcc, 
enabling it within gcc-3/libstdc++ needs strtof/strtold/snprintf, else 
strtod, one of finitef,finite,isinf,fabs/sscanf/sprintf (in c_locale.{h,cc})
so this seems rather a UCLIBC_HAS_FLOATS dependent option
gcc-4 has more checks to decide about USE_C99 (wchar/math tests) and has 
influence in more places of the code.

Thanks reading so far, Peter

> > > On the other hand, if you've got a bug report not specific to your branch,
> > > tell me and I'll fix it in my tree.  I already have several fixes there for
> > > problems that you and vapier have reported to me.  When we (i.e. my employer)
> > 
> > good to know that sometime a fix will come out ;-(
> 
> Of course they will.  What did you think?
> 
> > > release something using the updated version, I'll make thoses fixes available.
> > > But I'm generally not going to make fixes available to our competitors before
> > > we actually roll them out ourselves.
> > 
> > I don't have such limitations, I am/was not payed for any of my uClibc 
> > work.
> 
> There's a lot of work I've done on uClibc and busybox that I wasn't paid
> to do either.  But I'm far less inclined to hand out free lunches these
> days, for reasons I'll go into in my next post to this thread.
> 
> Manuel
> 
> 
> 

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list