libresolv Compile issue

Yorker · November 18, 2016 at 6:27 PM

Hi,

I've tried to build LE from scratch for wetek core and got the following error(should be related to my host lib i guess):

Code

make[3]: Entering directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/ssl'
make[3]: Nothing to be done for 'install-data-am'.
 /bin/mkdir -p '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.install_pkg/usr/lib'
 /bin/sh ../libtool   --mode=install /usr/bin/install -c   libssl.la '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.install_pkg/usr/lib'
libtool: install: warning: relinking `libssl.la'
libtool: install: (cd /mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/ssl; /bin/sh /mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/libtool  --silent --tag CC --mode=relink /mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/toolchain/bin/armv7a-libreelec-linux-gnueabi-gcc -march=armv7-a -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mcpu=cortex-a9 -mfloat-abi=hard -mfpu=neon-fp16 -fomit-frame-pointer -Wall -pipe -Os -flto -ffat-lto-objects -Wall -std=gnu99 -fno-strict-aliasing -fno-strict-overflow -fstack-protector-strong -Wno-pointer-sign -version-info 39:0:0 -no-undefined -march=armv7-a -mtune=cortex-a9 -Wl,--as-needed -fuse-ld=gold -fuse-linker-plugin -flto -Wl,-z,relro -Wl,-z,now -o libssl.la -rpath /usr/lib bio_ssl.lo bs_ber.lo bs_cbb.lo bs_cbs.lo d1_both.lo d1_clnt.lo d1_enc.lo d1_lib.lo d1_meth.lo d1_pkt.lo d1_srtp.lo d1_srvr.lo pqueue.lo s23_clnt.lo s23_lib.lo s23_pkt.lo s23_srvr.lo s3_both.lo s3_cbc.lo s3_clnt.lo s3_lib.lo s3_pkt.lo s3_srvr.lo ssl_algs.lo ssl_asn1.lo ssl_cert.lo ssl_ciph.lo ssl_err.lo ssl_err2.lo ssl_lib.lo ssl_rsa.lo ssl_sess.lo ssl_stat.lo ssl_txt.lo t1_clnt.lo t1_enc.lo t1_lib.lo t1_meth.lo t1_reneg.lo t1_srvr.lo /mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/crypto/libcrypto.la -lresolv -inst-prefix-dir /mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.install_pkg)
/usr/lib/libresolv.so: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
libtool: install: error: relink `libssl.la' with the above command before installing it
make[3]: *** [Makefile:392: install-libLTLIBRARIES] Error 1
make[3]: Leaving directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/ssl'
make[2]: *** [Makefile:600: install-am] Error 2
make[2]: Leaving directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi/ssl'
make[1]: *** [Makefile:451: install-recursive] Error 1
make[1]: Leaving directory '/mnt/share/Projects/LibreELEC.tv/build.LibreELEC-WeTek_Core.arm-8.0-devel/libressl-2.4.4/.armv7a-libreelec-linux-gnueabi'
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 2

Display More

Any idea?

**lrusak** · November 18, 2016 at 7:14 PM Official Post

It's picking up your host lib for some reason. No idea why.

Yorker · November 19, 2016 at 10:09 AM

That's what i have assumed, but a better question would be how do i debug it now?

**vpeter** · November 22, 2016 at 10:46 AM

I suspect this problem happen because of -rpath /usr/lib in command line when linking. Rpath is used to add folder for runtime linker but also when locating shared objects included in the link. I assume in this case libressl is installed on your host and it is picked because of this. But usually such incompatible binaries are just skipped. Not sure why this didn't happen in this case.

Yorker, put this patch file to folder packages/devel/binutils/patches. Remove whole build folder and build whole image again. I think it should fix your issue.

Please report back if it works or not.

**escalade** · November 22, 2016 at 12:14 PM

This is a "common" issue with the LE toolchain, it happens with quite a few packages from time to time (at least on Arch). I've had the same error when building for arm after the big autoreconf PR, some packages have been trying to link against /lib/libgcc which obviously won't work. Enabling autoreconf again fixes most of these, I had to do it for LibreSSL so you can give that a try.

vpeter

That looks very useful, perhaps it should be considered for inclusion in LE.

**vpeter** · November 22, 2016 at 12:33 PM

escalade, you are correct: enabling autoreconf should fix this issue because I don't see warning anymore with my patch. Seems this should be done for some other packages too (I noticed warnings with libressl, glib, libX11, libdrm, alsa-lib, and few others).
And yes, this patch will be PR-ed. First I need to build all projects to confirm they at least build.

**escalade** · November 22, 2016 at 3:34 PM

Yeah, same packages I noticed as well + libplist and libirman.

**awiouy** · November 22, 2016 at 4:32 PM Official Post

escalade see #974

Yorker · November 24, 2016 at 3:25 AM

vpeter

Your patch indeed fixed the issues and can be added to the master branch.

Thank you and everyone else for the support