Ok first two commands I get the same output like you. The third:
gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -L/usr/lib/ -lcrypto -lssl -static -print-file-name=libcrypto.a /usr/bin/ld: no input files collect2: ld returned 1 exit status The objdump returns elf32-i386 for all René 2009/7/28 Carl-Daniel Hailfinger <[email protected]> > On 28.07.2009 12:05, René Reuter wrote: > > I've changed that path already, tried every possibility. I even asked the > > gcc guys if they now any possibility how i could provide the lib, but it > > always crashes. > > > > (Any commands you have to run are preceded by a #) > > It doesn't crash, it just throws an undefined reference error. Looking > at the undefined reference error, it complains EVP_sha256 is missing. > Next question is why that symbol is missing although you had -lcrypto in > the command line. Run the following command: > # grep -l EVP_sha256 /usr/lib/libcrypto* > > Expected output is: > /usr/lib/libcrypto.a > /usr/lib/libcrypto.so > /usr/lib/libcrypto.so.0.9.8 > If /usr/lib/libcrypto.a is missing, it can't work (unless you're on > Debian/Ubuntu with that strange lib layout, and if that is the case, > please complain). Now run > # objdump -a /usr/lib/libcrypto.a|grep format > > Expected output is: > cryptlib.o: file format elf32-i386 > mem.o: file format elf32-i386 > mem_clr.o: file format elf32-i386 > mem_dbg.o: file format elf32-i386 > cversion.o: file format elf32-i386 > ex_data.o: file format elf32-i386 > [...] > If the output differs (maybe showing "file format elf64-x86-64"), it > can't work. Now run > #gcc -m32 -Wl,--build-id=none -nostdlib -nostartfiles -L/usr/lib/ > -lcrypto -lssl -static -print-file-name=libcrypto.a > > Expected output is: > /usr/lib/gcc/i586-suse-linux/4.2.1/../../../libcrypto.a > Run the objdump command from above for the file listed in the gcc > output. If the file format is not elf32-i386, it can't work. > > > And now the prize question: How did I arrive at the diagnosis above: > Simple. If the linker can't find some symbols, it means the required > library is not where gcc expects it. Three possible reasons for that: > 1. wrong library path > 2. wrong library type (dynamic instead of static) > 3. wrong architecture (x86_64 instead of i386) > Next, I opened the man page for gcc and searched for nostdlib. First hit > explains how to print the file name for any library you want gcc to use. > If that library does not match what gcc needs for linking your specific > project, gcc will complain during linking. > > Regards, > Carl-Daniel > > -- > http://www.hailfinger.org/ > >
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
