Re: problem compiling using libc6-dev in unstable

[Jim Pick <jim@jimpick.com>]

Alan Post <alan.post@usa.net> writes:

> I'm getting an error when I compile a program (hello world) on my netwinder:
> 
> 
> $ gcc -o test.o -c test.c
> $ gcc -o test test.o
> Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
> You have invoked `ld.so', the helper program for shared library executables.
> This program usually lives in the file `/lib/ld.so', and special directives
> in executable files using ELF shared libraries tell the system's program
> loader to load the helper program from this file.  This helper program loads
> the shared libraries needed by the program executable, prepares the program
> to run, and runs it.  You may invoke this helper program directly from the
> command line to load and run an ELF executable file; this is like executing
> that file itself, but always uses this helper program from the file you
> specified, instead of the helper program file specified in the executable
> file you run.  This is mostly of use for maintainers to test new versions
> of this helper program; chances are you did not intend to run this program.
>   --list                list all dependencies and how they are resolved
>   --verify              verify that given object really is a dynamically linked
>                         object we get handle
>   --library-path PATH   use given PATH instead of content of the environment
>                         variable LD_LIBRARY_PATH
>   --inhibit-rpath LIST  ignore RPATH information in object names in LIST
> collect2: ld returned 127 exit status
> $ 
> 
> 
> This only appears when using the libc6-dev from unstable (even the new
> 2.1.2-0pre7).  The program compiles fine when I have the libc from Jim Pick's
> transitional archive.  I'm currently using the gcc from the transitional
> archive but the binutils from unstable.  The gcc in unstable gives me other
> problems which I haven't made causal yet (sometimes I get the above message,
> sometimes it just segfaults, sometimes in gives me an error like "unsupported
> emulation mode: arm_linux  supported emulations: armelf32 armelf24 (off the
> top of my head, not the exact message).  The problem with this is I can run
> the new gcc twice in a row with the same command and get different error
> messages.)
> 
> What is going on here and how should I fix it?  Not having the unstable libc 
> causes problems with other libraries as well as perl (so those are
> transitional too).  I'd like to get a working toolchain that uses the newer 
> (and presumably less buggy) libc and gcc.
> 
> 
> Thank you,

You need to use gcc 2.95 from unstable, the binutils from
experimental, and a new kernel (2.2.1 doesn't work because it has a
broken vfork).

Cheers,

 - Jim