bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug-gnulib] getopt trouble on uClibc systems


From: Simon Josefsson
Subject: [Bug-gnulib] getopt trouble on uClibc systems
Date: Tue, 29 Jun 2004 20:27:53 +0200
User-agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux)

Hello.  I'm having problems with the getopt module with uClibc.  The
real source of the problem appear to be that uClibc uses header files
from GNU libc, but libc.a does not implement getopt_long.  The getopt
module doesn't use the normal autoconf approach -- test for a feature,
using e.g. AC_CHECK_FUNC(getopt_long, ...) -- but instead use the
ELIDE_CODE hack:

/* Comment out all this code if we are using the GNU C Library, and are not
   actually compiling the library itself.  This code is part of the GNU C
   Library, but also included in many other GNU distributions.  Compiling
   and linking in this code is a waste when using the GNU C library
   (especially if it is a shared library).  Rather than having every GNU
   program understand `configure --with-gnu-libc' and omit the object files,
   it is simpler to just do this in the source for each such file.  */

#define GETOPT_INTERFACE_VERSION 2
#if !defined _LIBC && defined __GLIBC__ && __GLIBC__ >= 2
#include <gnu-versions.h>
#if _GNU_GETOPT_INTERFACE_VERSION == GETOPT_INTERFACE_VERSION
#define ELIDE_CODE
#endif
#endif

On the uClibc platform, ELIDE_CODE ends up being defined, thus
removing the getopt_long implementation provided by gnulib.

I thought a simple solution to this could be to add to getopt.m4:

AC_CHECK_FUNC(getopt_long)

And then make sure the above magic in getopt*.c never define
ELIDE_CODE if HAVE_GETOPT_LONG is undefined.

Turns out this wasn't a simple solution:

m68k-uclinux-gcc -g -O2 -elf2flt -m5200 -o idn idn.o idn_cmd.o getopt.o 
getopt1.o  -L/usr/local/m68k-uclinux-tools/lib ../lib/.libs/libidn.a
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/lib/m5200/libc.a(getopt-susv3.o)(.bss+0x4):
 multiple definition of `optopt'
getopt.o(.data+0x0):/home/jas/src/libidn/src/getopt.c:194: first defined here
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/lib/m5200/libc.a(getopt-susv3.o)(.data+0x0):
 multiple definition of `optind'
getopt.o(.data+0x8):/home/jas/src/libidn/src/getopt.c:194: first defined here
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/lib/m5200/libc.a(getopt-susv3.o)(.data+0x4):
 multiple definition of `opterr'
getopt.o(.data+0x4):/home/jas/src/libidn/src/getopt.c:194: first defined here
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/lib/m5200/libc.a(getopt-susv3.o)(.text+0x0):
 In function `getopt':
: multiple definition of `getopt'
getopt.o(.text+0xb36):/home/jas/src/libidn/src/getopt.c:1179: first defined here
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/bin/ld.real:
 Warning: size of symbol `getopt' changed from 28 in getopt.o to 334 in 
/home/jas/m68k-uclinux-tools/bin/../lib/gcc/m68k-uclinux/3.4.0/../../../../m68k-uclinux/lib/m5200/libc.a(getopt-susv3.o)
collect2: ld returned 1 exit status

In other words, uClibc to implement part of the getopt interface,
presumably the POSIX part, and this interfere with the gnulib getopt
implementation.

My feelings are that the ELIDE_CODE approach is fragile, and should be
replaced by the normal autoconf approach: test for a feature, and add
a replacement when it is not present.

Perhaps another argument against ELIDE_CODE is that it generate empty
*.o and *.a:

address@hidden:/tmp/testdir/lib$ m68k-uclinux-nm -B ./libfoo.a
 
getopt.o:
 
getopt1.o:
address@hidden:/tmp/testdir/lib$

I'm on a ELF/FLT system, but IIRC some systems have problems with
empty archives.

It might be possible to create a new "getopt_long" module that only
implement the getopt_long function, given a POSIX getopt function.
I'm not sure if it is a good idea.

If anyone bothered to read this far have any ideas on solving this,
I'd appreciate them.

Calling this a uClibc bug is one (non-)solution, but I feel gnulib
should have handled this better.

Thanks,
Simon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]