[klibc] klibc 0.57 trouble

H. Peter Anvin
2002-08-25T02:27:32Z

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