uClibc snapshot + gettext = some minor issues

Peter S. Mazinger ps.m at gmx.net
Tue Jun 6 21:15:31 UTC 2006


On Tue, 6 Jun 2006, Robb, Sam wrote:

> Peter,
> 
>   Thanks for the reply.
> 
> > >   - error_print_progname is declared in a header, but the exported
> > >     variable definition is commented out.
> > 
> > search the archives about this one
> 
> I found the following thread - is this what you were refering to?
> 
>   http://www.uclibc.org/lists/uclibc/2006-March/014981.html
> 
> Later on in the thread, you made the following comment:
> 
>   http://www.uclibc.org/lists/uclibc/2006-March/015000.html
> 
>   "Why should a header provide a prototype for something that is not in 
>   libc.so? Why should libc.so provide a dummy error_print_progname() to get 
>   any app compiling?"
> 
> Now - whether or not gettext is using this glibc-specific global variable
> properly isn't the point I wanted to make.  As I said, I think that the
> way that gettext assumes the existence of and uses error_print_progname
> is broken. However...

later on I provided on ml (in May I think) the "real" implementation of 
it...

Peter
> 
> As far as I can tell, error_print_progname is a glibc extension.  As
> such, the glibc docs define how it should behave.  Section 2.3 of the
> glibc docs indicates that it's not only reasonable, but expected that
> error_print_progname may be NULL.  It's described as a global variable,
> provided by glibc, that may be set by a program, and which is referenced
> by the error and error_at_line functions.
> 
> So having an error_print_progname that is NULL isn't a dummy definition,
> it's an expected value for a global variable.  A quick test against glibc
> shows that the default value for error_print_progname is indeed NULL.
> 
> By including the declaration of error_print_progname in the uClibc headers,
> but no definition in a source file, uClibc has a broken implementation of
> error_print_progname.  Since this is a glibc extension, the *only* reason
> to implement it is to be compatible with glibc... and since the uClibc
> error_print_progname implementation, as it exists, *isn't* compatible with
> glibc, then it's broken.
> 
> Either uClibc shouldn't declare error_print_progname, or it should provide
> a global variable named error_print_progname that behaves in the same way
> as glibc.
> 
> > >   - The uClibc include/bits/uClibc_arch_features.h (pulled 
> > in by features.h,
> > >     which is pulled in by just about everything) 
> > indiscriminately defines
> > >     internal_function, which causes some linking problems 
> > in gettext.
> > 
> > a redefine shouldn't cause a link failure
> 
> It's not a redefine - it's just sloppy coding in gettext.  Because it only
> expects internal_function to be defined when building as part of glibc, when
> gettext builds outside of glibc, it ends up mixing up a couple of functions
> (declared as internal_function, but not defined as internal_function, or
> vice versa).
> 
> Here, the surprise wasn't the link errors - if internal_function *wasn't*
> defined, there would still be errors in gettext.  It was that there was
> what looked like an internal uClibc define "leaking out" into user space.
> 
> > that header should not get installed on final target 
> > probably, it should 
> > be used only for uClibc build-time.
> > gettext should though do 
> > #ifndef internal_function
> > #define internal_function blah
> > #endif
> > 
> > as do all the other gnulib sources
> 
> Definitely.  Like I said, gettext has a couple of problems along these lines.
> 
> -Samrobb
> 
> 

-- 
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