|
From: Greg P. <gp...@us...> - 2005-08-26 17:43:18
|
Julian Seward writes: > However: I can't get it to link with "-nodefaultlibs -lgcc". The > invokation and results are shown below. Anybody have any idea what > I should do? The no-linking-glibc-world is one I know nothing about. > > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0xc): In function > `_start': > ../sysdeps/i386/elf/start.S:109: undefined reference to `__libc_csu_fini' > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x11):../sysdeps/i386/elf/start.S:110: > undefined reference to `__libc_csu_init' > /usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../crt1.o(.text+0x1d):../sysdeps/i386/elf/start.S:119: > undefined reference to `__libc_start_main' > collect2: ld returned 1 exit status Currently, your build is still using the default crt1.o. In crt1.o, _start() calls __libc_csu_init() and __libc_start_main(), which are probably part of glibc's initialization. You might be able to get away with providing empty versions of those functions, since your pseudo-libc does all of its initialization in Valgrind's main(). (__libc_start_main() might be expected to call main() itself; check glibc's source.) Alternatively, you could link with -nostartfiles, which will omit crt1.o completely. In that case you need your own start.S that provides a _start() function that processes auxv and calls Valgrind's main(). You'd likely want to start with gcc's start.S (the one that becomes crt1.o) and hack from there. In either case, if Valgrind has any C++ static initializers or __attribute__((constructor)) functions, you'll need to handle them yourself. I expect that there aren't any. On Mac OS X and Valgrind 2.x, I used the second solution, because the default start files there have lots of historical ugliness. -- Greg Parker gp...@us... |