Skip to content
This repository has been archived by the owner on Apr 21, 2023. It is now read-only.

boringssl still compiled when using system libraries #1139

Closed
crowell opened this issue Sep 8, 2015 · 1 comment
Closed

boringssl still compiled when using system libraries #1139

crowell opened this issue Sep 8, 2015 · 1 comment

Comments

@crowell
Copy link
Contributor

crowell commented Sep 8, 2015

from email

Hi,

My openSUSE builds recently started failing for Tumbleweed ( which is a rolling release, so more a less or moving target in terms of the toolchain ). The specific error is at the end of the email. However I'm curious whether boringssl compilation can be skipped - I'm using use_system_libs = 1 and boringssl should not be necessary.

The build errors are

[  212s]   CC(target) out/Release/obj.target/openssl/third_party/boringssl/src/crypto/bn/add.o
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c: In function 'bio_ip_and_port_to_socket_and_addr':
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c:42:19: error: storage size of 'hint' isn't known
[  212s]    struct addrinfo hint, *result, *cur;
[  212s]                    ^
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c:51:9: warning: implicit declaration of function 'getaddrinfo' [-Wimplicit-function-declaration]
[  212s]    ret = getaddrinfo(hostname, port_str, &hint, &result);
[  212s]          ^
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c:54:27: warning: implicit declaration of function 'gai_strerror' [-Wimplicit-function-declaration]
[  212s]      ERR_add_error_data(1, gai_strerror(ret));
[  212s]                            ^
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c:60:36: error: dereferencing pointer to incomplete type 'struct addrinfo'
[  212s]    for (cur = result; cur; cur = cur->ai_next) {
[  212s]                                     ^
[  212s] third_party/boringssl/src/crypto/bio/socket_helper.c:79:3: warning: implicit declaration of function 'freeaddrinfo' [-Wimplicit-function-declaration]
[  212s]    freeaddrinfo(result);
[  212s]    ^
[  212s] third_party/serf/openssl.target.mk:616: recipe for target 'out/Release/obj.target/openssl/third_party/boringssl/src/crypto/bio/socket_helper.o' failed
[  212s] make: *** [out/Release/obj.target/openssl/third_party/boringssl/src/crypto/bio/socket_helper.o] Error 1
[  212s] make: *** Waiting for unfinished jobs....
[  212s] error: Bad exit status from /var/tmp/rpm-tmp.YI3n8A (%build)

GCC version is

$ gcc -v

Using built-in specs. 
COLLECT_GCC=gcc 
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/5/lto-wrapper 
Target: x86_64-suse-linux 
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go --enable-checking=release --with-gxx-incl
ude-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --enable-libmpx --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib -
-enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-ar
ch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux 
Thread model: posix 
gcc version 5.1.1 20150622 [gcc-5-branch revision 224722] (SUSE Linux)

Thanks,

Robert

@crowell
Copy link
Contributor Author

crowell commented Oct 7, 2015

pull request #1150 should fix this build error, boringssl will still build, but we'll still link against system libs. not ideal, so I'm not closing the bug yet.

jeffkaufman pushed a commit that referenced this issue Jan 29, 2016
don't incorrectly rely on boringssl directly from sha1 code, but rather go through our selector target (and similarly use it to find the includes) to find the ssl lib one is supposed to use.

Fixes #1139 too
jeffkaufman pushed a commit that referenced this issue Jan 29, 2016
don't incorrectly rely on boringssl directly from sha1 code, but rather go through our selector target (and similarly use it to find the includes) to find the ssl lib one is supposed to use.

Fixes #1139 too
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant