[coreboot] coreboot V2 with crypto library

[René Reuter]

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 <c-d.hailfinger.devel.2006 at gmx.net>

> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090728/f4d53b41/attachment.html>