klibc - Aug 2002 - klibc 0.57 trouble

Hi,

I just tried compiling the latest release, but found some new problems:

- Some versions of binutils could not link any shared binaries.
  One example for a broken version is 2.11.92.0.12.3, while 
  2.13.90.0.4 works. The error message looks like:
   tests/nfs_no_rpc.o: In function `root_nfs_parse':
   tests/nfs_no_rpc.o(.text+0x8): undefined reference to `strchr'
   tests/nfs_no_rpc.o(.text+0x10): undefined reference to `strtok'
   tests/nfs_no_rpc.o(.text+0x18): undefined reference to `strcmp'
   tests/nfs_no_rpc.o(.text+0x1c): undefined reference to `strtoul'
   tests/nfs_no_rpc.o(.text+0x2c): undefined reference to `strncpy'

- Digest::MD5 does not look like the perfect choice for versioning.
  On my system, it was not installed by default, and when I
  installed it, the generated md5 string contained the '/' character
  which can't be used in file names. Workaround is to use 
  ' md5hash.pl | tr / _ '

- gcc 3.0 and 3.2 don't like the memcpy and memset inline asm:
   memcpy.c: In function `memcpy':
   memcpy.c:16: invalid lvalue in asm statement

- I'm probably doing something wrong, but so far, I haven't been
  able to run any shared binaries. How are they supposed to
  work? I always get something like
   $ ./tests/minihello.shared
   bash: tests/minihello.shared: No such file or directory

there are also lots of compiler warnings:
- gcc 3.2 (i386) doesn't like the '-malign-functions=0 -malign-jumps=0 
  -malign-loops=0', it wants the '-falign...' versions instead,
which
  don't work with gcc 2.95 :(

- some of the asm/ kernel headers don't like being compiled with
'-W',
  e.g. asm-s390/bitops.h

- tests/testvsnp.c causes lots of warnings when compiled with gcc-3.2
  or when size_t is not int.

I can probably the new arch/s390{,x} files next week when I have
run the test programs.
BTW: are there any plans to make a busybox variant work with klibc
or to use the same concept for the programs shipped with it?

	Arnd <><

Arnd Bergmann wrote:
> Hi,
> 
> I just tried compiling the latest release, but found some new problems:
Which platform is this on?
> - Some versions of binutils could not link any shared binaries.
>   One example for a broken version is 2.11.92.0.12.3, while 
>   2.13.90.0.4 works. The error message looks like:
>    tests/nfs_no_rpc.o: In function `root_nfs_parse':
>    tests/nfs_no_rpc.o(.text+0x8): undefined reference to `strchr'
>    tests/nfs_no_rpc.o(.text+0x10): undefined reference to `strtok'
>    tests/nfs_no_rpc.o(.text+0x18): undefined reference to `strcmp'
>    tests/nfs_no_rpc.o(.text+0x1c): undefined reference to `strtoul'
>    tests/nfs_no_rpc.o(.text+0x2c): undefined reference to `strncpy'
> 
> - Digest::MD5 does not look like the perfect choice for versioning.
>   On my system, it was not installed by default, and when I
>   installed it, the generated md5 string contained the '/'
character
>   which can't be used in file names. Workaround is to use 
>   ' md5hash.pl | tr / _ '
This is fixed in CVS.
> - gcc 3.0 and 3.2 don't like the memcpy and memset inline asm:
>    memcpy.c: In function `memcpy':
>    memcpy.c:16: invalid lvalue in asm statement
This is extremely odd.  I will look into it.
> - I'm probably doing something wrong, but so far, I haven't been
>   able to run any shared binaries. How are they supposed to
>   work? I always get something like
>    $ ./tests/minihello.shared
>    bash: tests/minihello.shared: No such file or directory
You need to get the klibc-<md5>.so file symlinked into /lib.
> there are also lots of compiler warnings:
> - gcc 3.2 (i386) doesn't like the '-malign-functions=0
-malign-jumps=0
>   -malign-loops=0', it wants the '-falign...' versions instead,
which
>   don't work with gcc 2.95 :(
Compiler braindamage.  Nothing I can do about it :(
> - some of the asm/ kernel headers don't like being compiled with
'-W',
>   e.g. asm-s390/bitops.h
That I consider a kernel header bug.
> - tests/testvsnp.c causes lots of warnings when compiled with gcc-3.2
>   or when size_t is not int.
I know about this one... I will work at it.
> I can probably the new arch/s390{,x} files next week when I have
> run the test programs.
> BTW: are there any plans to make a busybox variant work with klibc
> or to use the same concept for the programs shipped with it?
Not clear yet.

	-hpa