Issue 452464 in chromium: Can't compile shared library of BoringSSL

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Pri-2 Via-Wizard Type-Bug OS-Linux

New issue 452464 by lmini...@gmail.com: Can't compile shared library of
BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/41.0.2224.3 Safari/537.36

Steps to reproduce the problem:
I tried to ask about this problem on the discuss-webrtc but I got no
response, so I'm trying here now. I'm trying to compile BoringSSL as a
library to use in another probject, so this is not Chrome related: anyway,
I found other BoringSSL related issues notified here so I thought I'd ask
here too. If this is not the place to ask, please refer me to the proper
place to do so, as I couldn't find anything by myself.

About the issue, I'm trying to compile a shared version of BoringSSL on a
64-bit Fedora, and failed so far. I changed the STATIC in
crypto/CMakeLists.txt and ssl/CMakeLists.txt to SHARED and I added the
-DBORINGSSL_SHARED_LIBRARY definition to the already existing
-DBORINGSSL_IMPLEMENTATION, as suggested in the BUILDING doc. I also had to
remove the -Wshadow flag as it gave a warning on my compiler which caused
an error (all warnings are treated as errors). That said, the linking fails
(details below).

What is the expected behavior?
A shared build of libssl.so and libcrypto.so

What went wrong?
Everything seems to go fine until it's time to link:

Linking C shared library libcrypto.so
/usr/bin/ld: sha/CMakeFiles/sha.dir/sha1-x86_64.S.o: relocation
R_X86_64_PC32 against symbol `OPENSSL_ia32cap_P' can not be used when
making a shared object; recompile with -fPIC

I already tried setting the -fPIC in several different ways as suggested,
but that didn't solve it. When inspecting with readelf, I get this, so this
might be a different issue:

readelf --relocs crypto/sha/CMakeFiles/sha.dir/sha1-x86_64.S.o

Relocation section '.rela.text' at offset 0x2370 contains 3 entries:
Offset Info Type Sym. Value Sym. Name +
Addend
000000000003 000800000002 R_X86_64_PC32 0000000000000000
OPENSSL_ia32cap_P - 4
00000000000a 000800000002 R_X86_64_PC32 0000000000000000
OPENSSL_ia32cap_P + 0
000000000011 000800000002 R_X86_64_PC32 0000000000000000
OPENSSL_ia32cap_P + 4

Did this work before? N/A

Chrome version: 41.0.2224.3 Channel: n/a
OS Version:
Flash Version: Shockwave Flash 15.0 r0

Any clue? Is this a bug in the cmake setup, or something wrong in my
environment?

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Updates:
Cc: davi...@chromium.org a...@chromium.org
Labels: Cr-Internals-Network-SSL

Comment #1 on issue 452464 by m...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #2 on issue 452464 by rsl...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

At this time, BoringSSL is not officially supported on Linux platforms.

By officially supported, I mean used by Chrome and integrated into our
testing waterfall.

[chro...@googlecode.com]

Comment #3 on issue 452464 by davi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

This looks like it's because the standalone build doesn't run x86 perlasm
with -fPIC, which is needed for shared libraries. I don't think we
currently have any supported use where we need to build a shared library
out of the standalone build, but since we're building Chromium that way for
the component build, it's probably worth matching.

https://boringssl-review.googlesource.com/#/c/3063/

[chro...@googlecode.com]

Comment #4 on issue 452464 by davi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

Actually, nevermind. You're on x86-64 which we don't pass anything to in
Chromium[*], yet the components build does fine. So that change probably
won't help you, though it's probably still worthwhile on our end.

[*]
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/boringssl/update_gypi_and_asm.py&l=15

[chro...@googlecode.com]

Updates:
Cc: chi...@chromium.org
Labels: TE-NeedsFurtherTriage

Comment #5 on issue 452464 by chi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #6 on issue 452464 by davi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

I was bored and toyed with this a bit. The problem is that the standalone
build doesn't build with -fvisibility=hidden (nor does it link with
-Bsymbolic), and so the linker is trying to generate a relocation for the
OPENSSL_ia32cap_P when it should just do a PC-relative address. That's
probably still worth resolving for the sake of matching the Chromium build,
though I'd have to check if we build that way in the static library build
too.

Fixing that then uncovers another issue that nothing in
include/openssl/conf.h includes OPENSSL_EXPORT, so conf_test will fail to
link. That one's going to bite when we roll into Chromium anyway and is
easy to fix.

[chro...@googlecode.com]

Comment #7 on issue 452464 by lmini...@gmail.com: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

Thanks for looking into this!

[chro...@googlecode.com]

Updates:
Status: Fixed

Comment #8 on issue 452464 by davi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

As of
https://boringssl.googlesource.com/boringssl/+/507c1eec51b51f09d922b76e088f89fbb66b6161,
it should be much easier to get a shared library out if you want that for
some reason.

[chro...@googlecode.com]

Comment #11 on issue 452464 by lmini...@gmail.com: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

Not sure if anything has been fixed in the meanwhile, but I can get a
shared library if I follow these steps:

git clone https://boringssl.googlesource.com/boringssl
cd boringssl
sed -i s/-Werror//g CMakeLists.txt
mkdir build
cd build
cmake -DBUILD_SHARED_LIBS=1 -DCMAKE_CXX_FLAGS="-lrt" ..
make

The sed part is needed because there's a warning when building bio_test,
that causes the build process to fail:

[ 83%] Building CXX object crypto/bn/CMakeFiles/bn_test.dir/bn_test.cc.o
/home/lminiero/workspace/boringssl/crypto/bn/bn_test.cc: In function ‘bool
test_small_prime(FILE*, BN_CTX*)’:
/home/lminiero/workspace/boringssl/crypto/bn/bn_test.cc:1353:31: error:
comparison between signed and unsigned integer expressions
[-Werror=sign-compare]
cc1plus: all warnings being treated as errors
make[2]: *** [crypto/bn/CMakeFiles/bn_test.dir/bn_test.cc.o] Error 1
make[1]: *** [crypto/bn/CMakeFiles/bn_test.dir/all] Error 2
make: *** [all] Error 2

The manual addition -lrt instead is needed when building bssl, because
otherwise there's an undefined reference to clock_gettime:

Linking CXX executable bssl
CMakeFiles/bssl.dir/speed.cc.o: In function `time_now':
/home/lminiero/workspace/boringssl/tool/speed.cc:86: undefined reference to
`clock_gettime'
collect2: error: ld returned 1 exit status
make[2]: *** [tool/bssl] Error 1
make[1]: *** [tool/CMakeFiles/bssl.dir/all] Error 2
make: *** [all] Error 2

Fixing those two parts does generate the shared objects for libcrypto and
libssl, although I haven't tested them yet (but I have no reason to believe
they won't work).

[chro...@googlecode.com]

Comment #12 on issue 452464 by davi...@chromium.org: Can't compile shared

library of BoringSSL
https://code.google.com/p/chromium/issues/detail?id=452464

Oh, that must have been why we had -lrt. I wonder why it builds on our end.
I'll go fix that and the warning. Thanks! I'm guessing your version of gcc
is more finicky.

Yeah, the shared library build should now work. However note that we do NOT
promise any kind of API or ABI stability and certainly not ABI
compatibility with OpenSSL. I got it working because some of our build
configurations are similar to it, but it's not suitable for any kind of
exposed system library.