> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker > script and no longer a symlink. This breaks the config check on i386 for > what binary format to use when building with ASM support. The current > config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X > file to run file(1) against. For FreeBSD the real libc.so is in > /lib/libc.so.X. > > Because the proper libc.so is not found, a.out format is chosen when > using ASM and the build fails. > > With patch: > Operating system: i386-pc-freebsd8.3 > Configuring for BSD-x86-elf > [...] > Build passes. > > > I have 2 proposed patches which solve the problem. Only 1 is needed. > > 1. Use file(1) against /bin/sh for all BSD platforms. I believe this > will be more portable long-term. It will determine the binary type, > regardless of where libc.so is or how it is setup. Note that -L is used > to follow symlink incase someone symlinks /bin/sh to something else. > > http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-bin-sh.diff > > 2. Or just include /lib/libc.so.* in the search path to run file(1) > against. I prefer #1 as it is possible that /usr/lib/libc.so is > symlinked to a libc.ld script, which cause file(1) to return 'ASCII' and > the config falls back on a.out. > > http://people.freebsd.org/~bdrewery/openssl-ldscript-elf-lib-libc.diff
We have to remember that those lines serve several BSD flavours and preferred choice should be least invasive, i.e. #2. But before we proceed could you answer couple of questions? Is it possible to run 32-bit x86 binaries on x86_64 FreeBSD system? Compile 32-bit program? How multi-lib is handled, i.e. where are 32- and 64-bit shared libraries reside? Well, this is unlikely to affect the decision, I'm simply using the opportunity to learn something that can affect future decisions. Thanks. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
