* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24
@ 2017-01-25 7:30 Thomas Petazzoni
2017-01-25 21:05 ` Jörg Krause
0 siblings, 1 reply; 29+ messages in thread
From: Thomas Petazzoni @ 2017-01-25 7:30 UTC (permalink / raw)
To: buildroot
Hello,
Build statistics for 2017-01-24
================================
successes : 101
failures : 44
timeouts : 1
TOTAL : 146
Classification of failures by reason
====================================
mediastreamer-2.12.1 | 12
ruby-2.4.0 | 6
sdl2_ttf-2.0.14 | 6
samba4-4.5.4 | 4
openswan-2.6.46 | 2
bctoolbox-0.4.0 | 1
cups-2.2.2 | 1
glmark2-fa71af2dfab711fac87... | 1
ipmiutil-2.9.9 | 1
log4cxx-0.10.0 | 1
lttng-libust-2.9.0 | 1
make: *** wait: No child pr... | 1
netsniff-ng-v0.6.2 | 1
openvpn-2.3.14 | 1
python-libconfig-b271c3d9da... | 1
upmpdcli-1.2.10 | 1
vpnc-b1243d29e0c00312ead038... | 1
xen-4.7.1 | 1
xorriso-1.4.2 | 1
xserver_xorg-server-1.19.1 | 1
Detail of failures
===================
i586 | bctoolbox-0.4.0 | NOK | http://autobuild.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364
i586 | cups-2.2.2 | NOK | http://autobuild.buildroot.net/results/61cf6659357795f3de69bb00c4000f049e946424
arm | glmark2-fa71af2dfab711fac87... | NOK | http://autobuild.buildroot.net/results/8dc9400505b9087ce290981d95486598df0beb56
i586 | ipmiutil-2.9.9 | NOK | http://autobuild.buildroot.net/results/cd1569596ce610a3c8c7747e7b31807f8c6abbf8
nios2 | log4cxx-0.10.0 | NOK | http://autobuild.buildroot.net/results/d9825870993f47e3850d3e3a95ae4f494dceaf0e
x86_64 | lttng-libust-2.9.0 | NOK | http://autobuild.buildroot.net/results/57adda12f17593ac1e79e7e472a93162cc693463
mips64el | make: *** wait: No child pr... | TIM | http://autobuild.buildroot.net/results/ff5723f7ef4d5bb191d125b1881542f482f5b390
m68k | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/9aa3cdad6e22ad1656eec59fc92fb7cb79afc4cd
mips64el | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/09e8fabb72cafa284419f096da95299c51c03899
nios2 | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/29c8ddd25c76f4c5b74f31a576c7ace9f76677db
xtensa | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/ccb6a981b5df303939dcd78b4517bfb44498bdd0
powerpc | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/96f6aab9b5b81e2e6654789704eb89abc36cacdf
x86_64 | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/a0c37fd7f3ae541c29dcd1a092383712ef3363e4
arc | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/f98685aee3dcfb21c1fd86654bed0f96784a6c6d
powerpc | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/20744d0b8b6833baabb53af93c471c427a1455f5
aarch64 | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/a888482327a6cdb45ac929d07d67315b241a2d73
arc | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/9aacaefd9cf995b692b34ff8f6cc19f4d918c9bf
x86_64 | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/7be5c3adbc22a41a069b66f7a1870f8e519d05b8
mipsel | mediastreamer-2.12.1 | NOK | http://autobuild.buildroot.net/results/15c6a841f37efb8dfd23e7e3db33e01375351ae2
i586 | netsniff-ng-v0.6.2 | NOK | http://autobuild.buildroot.net/results/6eb77ab3c31267b2d314b4eff12d1581e2441e85
arm | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/ab6e68a03d2e3687e67a959b02afd613d468eaef
powerpc | openswan-2.6.46 | NOK | http://autobuild.buildroot.net/results/ace4906237590f0d6eb3bf051951f77c2f8acbfd
arm | openvpn-2.3.14 | NOK | http://autobuild.buildroot.net/results/25be1c34b542a44e5c685e4d672ce52ba8c7f1b0
x86_64 | python-libconfig-b271c3d9da... | NOK | http://autobuild.buildroot.net/results/166ab6ed51daf6da3d4dfcb908704a68d9527a3b
i686 | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/4af4df1645d43afb161e404e437b4dd5dc323c42
mips64el | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/443242707275dc72070e0772b9f148558b63fb3a
x86_64 | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/f04ce59f277f33a399e7e88868dc05ac3df2a95c
bfin | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/c8b5f368e8180baf10e002fdf096f363a67a350b
m68k | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/2dd63b904456bcfb8317559d9adb4bdde340aafb
arc | ruby-2.4.0 | NOK | http://autobuild.buildroot.net/results/f28039fa9b370c77d6be9518ec8dd3055c50a14d
sh4 | samba4-4.5.4 | NOK | http://autobuild.buildroot.net/results/27440387caa35b0225aeda5dec43a1bf914c68aa
x86_64 | samba4-4.5.4 | NOK | http://autobuild.buildroot.net/results/320725ccb206f2f2388c032f21e6b862756f0827
sh4a | samba4-4.5.4 | NOK | http://autobuild.buildroot.net/results/8c8e6b8cd2e15df97063673da9a58e66ad51ad74
aarch64 | samba4-4.5.4 | NOK | http://autobuild.buildroot.net/results/9306fd82a532c6a22092e4ec7fcd6bda873c2269
sh4 | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/ba70748271c16664bcf9a0b353c52e1a784426a2
arc | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/0b355b8c08fdcedb0c7267d133dcadfe5093a7d9
arm | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/ba5ec1e2a5821cd3d234df06d5486b0484629b26
sparc | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/175d9644516c71764247fad47a36b2acc42fa142
arm | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/6c0eb6cd9887c28859ecadc9404d67f58b8717b0
sparc64 | sdl2_ttf-2.0.14 | NOK | http://autobuild.buildroot.net/results/cbeca644e9924eb44a9e914fc4e956a51ca8c1f9
arm | upmpdcli-1.2.10 | NOK | http://autobuild.buildroot.net/results/4aa075b61ea012f41e808587c675fbff1ea641df
mips64el | vpnc-b1243d29e0c00312ead038... | NOK | http://autobuild.buildroot.net/results/25b2e19ad82c1dfefaa00b541d23b265e07fe0c6
arm | xen-4.7.1 | NOK | http://autobuild.buildroot.net/results/53421acb92eddba2c37b3ef6d44b05070a90bdfc
mips64el | xorriso-1.4.2 | NOK | http://autobuild.buildroot.net/results/14581a3257eedc2c325fe454dda1e4532ab98002
mips64el | xserver_xorg-server-1.19.1 | NOK | http://autobuild.buildroot.net/results/fb56794b4b5c206d260d1aa221c929b142712990
--
http://autobuild.buildroot.net
^ permalink raw reply [flat|nested] 29+ messages in thread* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-25 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 Thomas Petazzoni @ 2017-01-25 21:05 ` Jörg Krause 2017-01-25 21:15 ` Baruch Siach 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-01-25 21:05 UTC (permalink / raw) To: buildroot On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: > Hello, [snip] > Detail of failures > =================== > > ????????i586 |????????????????bctoolbox-0.4.0 | NOK | http://autobuil > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364 Unfortunately I cannot reproduce this issue. Is it a rpath issue? cmake links a test program with host zlib: [..]/i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed by /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' I have no idea how to fix it. bctoolbox' cmakelists.txt does set CMAKE_INSTALL_RPATH=/usr/lib. Is this a problem? Best regards, J?rg Krause ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-25 21:05 ` Jörg Krause @ 2017-01-25 21:15 ` Baruch Siach 2017-01-26 11:04 ` Samuel Martin 0 siblings, 1 reply; 29+ messages in thread From: Baruch Siach @ 2017-01-25 21:15 UTC (permalink / raw) To: buildroot Hi J?rg, On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: > [snip] > > > Detail of failures > > =================== > > > > ????????i586 |????????????????bctoolbox-0.4.0 | NOK | http://autobuil > > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364 > > Unfortunately I cannot reproduce this issue. Is it a rpath issue? cmake > links a test program with host zlib: > > [..]/i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed by > /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) > /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' This is your host library. > I have no idea how to fix it. bctoolbox' cmakelists.txt does set > CMAKE_INSTALL_RPATH=/usr/lib. Is this a problem? That is definitely not compatible with cross compilation. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-25 21:15 ` Baruch Siach @ 2017-01-26 11:04 ` Samuel Martin 2017-01-26 11:11 ` Baruch Siach 2017-01-29 20:37 ` Jörg Krause 0 siblings, 2 replies; 29+ messages in thread From: Samuel Martin @ 2017-01-26 11:04 UTC (permalink / raw) To: buildroot Hi all, On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> wrote: > Hi J?rg, > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: >> On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: >> [snip] >> >> > Detail of failures >> > =================== >> > >> > i586 | bctoolbox-0.4.0 | NOK | http://autobuil >> > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364 Regarding this package, apologies I missed it during the initial review :s This build failure occurs because it goes in a path it should not. In the Config.in: it is mentionned that mbedtls is prefered to polarssl [1], hence the select [1] and the dependency in the *.mk [2]. However, the cmake configure flags are not set accordingly to this, and the defaults may play against us [3]. I would suggest to set the ENABLE_{MBEDTLS,POLARSSL} flags in the *.mk first. This should prevent from following this case [4], as displayed in the build log [5]. After this, if the CheckSymbolExists still causes error, we may need to patch the bctoolbox cmake code to set/fix the variables used by CheckSymbolExists [6]. >> >> Unfortunately I cannot reproduce this issue. Is it a rpath issue? cmake >> links a test program with host zlib: Note: I'm not able to reproduce the error either. >> >> [..]/i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed by >> /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) >> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' > > This is your host library. > >> I have no idea how to fix it. bctoolbox' cmakelists.txt does set >> CMAKE_INSTALL_RPATH=/usr/lib. Is this a problem? > > That is definitely not compatible with cross compilation. > > baruch > > -- > http://baruch.siach.name/blog/ ~. .~ Tk Open Systems > =}------------------------------------------------ooO--U--Ooo------------{= > - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - > _______________________________________________ > buildroot mailing list > buildroot at busybox.net > http://lists.busybox.net/mailman/listinfo/buildroot Regards, [1] https://git.buildroot.net/buildroot/tree/package/bctoolbox/Config.in#n5 [2] https://git.buildroot.net/buildroot/tree/package/bctoolbox/bctoolbox.mk#n11 [3] https://github.com/BelledonneCommunications/bctoolbox/blob/master/CMakeLists.txt#L44 [4] https://github.com/BelledonneCommunications/bctoolbox/blob/master/CMakeLists.txt#L88 [5] http://autobuild.buildroot.net/results/4b4/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364/build-end.log [6] https://cmake.org/cmake/help/v3.0/module/CheckSymbolExists.html -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-26 11:04 ` Samuel Martin @ 2017-01-26 11:11 ` Baruch Siach 2017-01-26 11:14 ` Jörg Krause 2017-01-29 20:37 ` Jörg Krause 1 sibling, 1 reply; 29+ messages in thread From: Baruch Siach @ 2017-01-26 11:11 UTC (permalink / raw) To: buildroot Hi Samuel, On Thu, Jan 26, 2017 at 12:04:41PM +0100, Samuel Martin wrote: > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> wrote: > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > >> On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: > >> [snip] > >> > >> > Detail of failures > >> > =================== > >> > > >> > i586 | bctoolbox-0.4.0 | NOK | http://autobuil > >> > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9364 > > Regarding this package, apologies I missed it during the initial review :s > > This build failure occurs because it goes in a path it should not. > In the Config.in: it is mentionned that mbedtls is prefered to > polarssl [1], hence the select [1] and the dependency in the *.mk [2]. > However, the cmake configure flags are not set accordingly to this, > and the defaults may play against us [3]. > > I would suggest to set the ENABLE_{MBEDTLS,POLARSSL} flags in the *.mk first. > This should prevent from following this case [4], as displayed in the > build log [5]. > > After this, if the CheckSymbolExists still causes error, we may need > to patch the bctoolbox > cmake code to set/fix the variables used by CheckSymbolExists [6]. > > >> > >> Unfortunately I cannot reproduce this issue. Is it a rpath issue? cmake > >> links a test program with host zlib: > > Note: I'm not able to reproduce the error either. Do you have a 32bit libz.so.1 in /usr/lib on your host machine? > >> [..]/i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed by > >> /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) > >> /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-26 11:11 ` Baruch Siach @ 2017-01-26 11:14 ` Jörg Krause 2017-01-26 11:28 ` Baruch Siach 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-01-26 11:14 UTC (permalink / raw) To: buildroot Hi Baruch, On Thu, 2017-01-26 at 13:11 +0200, Baruch Siach wrote: > Hi Samuel, > > On Thu, Jan 26, 2017 at 12:04:41PM +0100, Samuel Martin wrote: > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> > > wrote: > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > > On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: > > > > [snip] > > > > > > > > > Detail of failures > > > > > =================== > > > > > > > > > > ????????i586 |????????????????bctoolbox-0.4.0 | NOK | http:// > > > > > autobuil > > > > > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c9 > > > > > 364 > > > > Regarding this package, apologies I missed it during the initial > > review :s > > > > This build failure occurs because it goes in a path it should not. > > In the Config.in: it is mentionned that mbedtls is prefered to > > polarssl [1], hence the select [1] and the dependency in the *.mk > > [2]. > > However, the cmake configure flags are not set accordingly to this, > > and the defaults may play against us [3]. > > > > I would suggest to set the ENABLE_{MBEDTLS,POLARSSL} flags in the > > *.mk first. > > This should prevent from following this case [4], as displayed in > > the > > build log [5]. > > > > After this, if the CheckSymbolExists still causes error, we may > > need > > to patch the bctoolbox > > cmake code to set/fix the variables used by CheckSymbolExists [6]. > > > > > > > > > > Unfortunately I cannot reproduce this issue. Is it a rpath > > > > issue? cmake > > > > links a test program with host zlib: > > > > Note: I'm not able to reproduce the error either. > > Do you have a 32bit libz.so.1 in /usr/lib on your host machine? I do have: ls -l /usr/lib??/libz.so.1 lrwxrwxrwx 1 root root 14 15. Jan 20:46 /usr/lib32/libz.so.1 -> libz.so.1.2.11* lrwxrwxrwx 1 root root 14 15. Jan 20:43 /usr/lib64/libz.so.1 -> libz.so.1.2.11* J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-26 11:14 ` Jörg Krause @ 2017-01-26 11:28 ` Baruch Siach 0 siblings, 0 replies; 29+ messages in thread From: Baruch Siach @ 2017-01-26 11:28 UTC (permalink / raw) To: buildroot Hi J?rg, On Thu, Jan 26, 2017 at 12:14:04PM +0100, J?rg Krause wrote: > On Thu, 2017-01-26 at 13:11 +0200, Baruch Siach wrote: > > On Thu, Jan 26, 2017 at 12:04:41PM +0100, Samuel Martin wrote: > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> > > > wrote: > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > > > Unfortunately I cannot reproduce this issue. Is it a rpath > > > > > issue? cmake > > > > > links a test program with host zlib: > > > > > > Note: I'm not able to reproduce the error either. > > > > Do you have a 32bit libz.so.1 in /usr/lib on your host machine? > > I do have: > > ls -l /usr/lib??/libz.so.1 > lrwxrwxrwx 1 root root 14 15. Jan 20:46 /usr/lib32/libz.so.1 -> > libz.so.1.2.11* > lrwxrwxrwx 1 root root 14 15. Jan 20:43 /usr/lib64/libz.so.1 -> > libz.so.1.2.11* On a recent Debian Testing I have lib32z1 installed and: ls -l /usr/lib32/libz.so.1 lrwxrwxrwx 1 root root 13 Dec 7 17:43 /usr/lib32/libz.so.1 -> libz.so.1.2.8 I can reproduce this failure here. The failed gcc invocation in CMakeError.log includes -Wl,-rpath,/usr/lib32, which is clearly incompatible with cross compiling. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-26 11:04 ` Samuel Martin 2017-01-26 11:11 ` Baruch Siach @ 2017-01-29 20:37 ` Jörg Krause 2017-01-29 21:11 ` Baruch Siach 1 sibling, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-01-29 20:37 UTC (permalink / raw) To: buildroot Hi Samuel, On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > Hi all, > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> > wrote: > > Hi J?rg, > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > On Wed, 2017-01-25 at 08:30 +0100, Thomas Petazzoni wrote: > > > [snip] > > > > > > > Detail of failures > > > > =================== > > > > > > > > ????????i586 |????????????????bctoolbox-0.4.0 | NOK | http://au > > > > tobuil > > > > d.buildroot.net/results/4b4b00ad3b95ddacc9d5cc31c34e457ee55c936 > > > > 4 > > Regarding this package, apologies I missed it during the initial > review :s Never mind! That's the autobuilder are there for, right? > This build failure occurs because it goes in a path it should not. > In the Config.in: it is mentionned that mbedtls is prefered to > polarssl [1], hence the select [1] and the dependency in the *.mk > [2]. > However, the cmake configure flags are not set accordingly to this, > and the defaults may play against us [3]. > > I would suggest to set the ENABLE_{MBEDTLS,POLARSSL} flags in the > *.mk first. > This should prevent from following this case [4], as displayed in the > build log [5]. Support for PolarSSL is only enabled if mbedTLS is not found, but I agree, it's better to disable it explicitly. > After this, if the CheckSymbolExists still causes error, we may need > to patch the bctoolbox > cmake code to set/fix the variables used by CheckSymbolExists [6]. I prepared a patch of FindMbedTLS.cmake which checks if mbedtls was build with libz support and if so, add libz to MBEDTLS_LIBRARIES. This way, CMake should take care of linking against the libz in sysroot. > > > > > > Unfortunately I cannot reproduce this issue. Is it a rpath issue? > > > cmake > > > links a test program with host zlib: > > Note: I'm not able to reproduce the error either. I wonder, what makes the difference to be able to reproduce the issue. > > > > > > [..]/i586-buildroot-linux-musl/bin/ld: warning: libc.so.6, needed > > > by > > > /usr/lib32/libz.so.1, not found (try using -rpath or -rpath-link) > > > /usr/lib32/libz.so.1: undefined reference to `strcpy at GLIBC_2.0' > > > > This is your host library. > > > > > I have no idea how to fix it. bctoolbox' cmakelists.txt does set > > > CMAKE_INSTALL_RPATH=/usr/lib. Is this a problem? > > > > That is definitely not compatible with cross compilation. > > > > baruch > > > > -- > > ?????http://baruch.siach.name/blog/??????????????????~. .~???Tk > > Open Systems > > =}------------------------------------------------ooO--U--Ooo---- > > --------{= > > ???- baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co. > > il - > > _______________________________________________ > > buildroot mailing list > > buildroot at busybox.net > > http://lists.busybox.net/mailman/listinfo/buildroot > > Regards, > > [1] https://git.buildroot.net/buildroot/tree/package/bctoolbox/Config > .in#n5 > [2] https://git.buildroot.net/buildroot/tree/package/bctoolbox/bctool > box.mk#n11 > [3] https://github.com/BelledonneCommunications/bctoolbox/blob/master > /CMakeLists.txt#L44 > [4] https://github.com/BelledonneCommunications/bctoolbox/blob/master > /CMakeLists.txt#L88 > [5] http://autobuild.buildroot.net/results/4b4/4b4b00ad3b95ddacc9d5cc > 31c34e457ee55c9364/build-end.log > [6] https://cmake.org/cmake/help/v3.0/module/CheckSymbolExists.html > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-29 20:37 ` Jörg Krause @ 2017-01-29 21:11 ` Baruch Siach 2017-01-30 19:59 ` Jörg Krause 0 siblings, 1 reply; 29+ messages in thread From: Baruch Siach @ 2017-01-29 21:11 UTC (permalink / raw) To: buildroot Hi J?rg, On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il> > > wrote: > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > > Unfortunately I cannot reproduce this issue. Is it a rpath issue? > > > > cmake links a test program with host zlib: > > > > Note: I'm not able to reproduce the error either. > > I wonder, what makes the difference to be able to reproduce the issue. See http://lists.busybox.net/pipermail/buildroot/2017-January/182237.html. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-29 21:11 ` Baruch Siach @ 2017-01-30 19:59 ` Jörg Krause 2017-01-30 21:20 ` Baruch Siach 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-01-30 19:59 UTC (permalink / raw) To: buildroot Hi Baruch, On Sun, 2017-01-29 at 23:11 +0200, Baruch Siach wrote: > Hi J?rg, > > On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il > > > > > > > wrote: > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > > > Unfortunately I cannot reproduce this issue. Is it a rpath > > > > > issue? > > > > > cmake links a test program with host zlib: > > > > > > Note: I'm not able to reproduce the error either. > > > > I wonder, what makes the difference to be able to reproduce the > > issue. > > See http://lists.busybox.net/pipermail/buildroot/2017-January/182237. > html. I setup a Debian and Scientific Linux system yesterday, but I still cannot reproduce the build issue. However, I've found out that mbedlts is never build with zlib support in Buildroot [1]. [1] http://patchwork.ozlabs.org/patch/721218/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-30 19:59 ` Jörg Krause @ 2017-01-30 21:20 ` Baruch Siach 2017-01-30 21:22 ` Jörg Krause 0 siblings, 1 reply; 29+ messages in thread From: Baruch Siach @ 2017-01-30 21:20 UTC (permalink / raw) To: buildroot Hi J?rg, On Mon, Jan 30, 2017 at 08:59:02PM +0100, J?rg Krause wrote: > On Sun, 2017-01-29 at 23:11 +0200, Baruch Siach wrote: > > Hi J?rg, > > > > On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > > > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.co.il > > > > wrote: > > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause wrote: > > > > > > Unfortunately I cannot reproduce this issue. Is it a rpath > > > > > > issue? > > > > > > cmake links a test program with host zlib: > > > > > > > > Note: I'm not able to reproduce the error either. > > > > > > I wonder, what makes the difference to be able to reproduce the > > > issue. > > > > See http://lists.busybox.net/pipermail/buildroot/2017-January/182237.html. > > I setup a Debian and Scientific Linux system yesterday, but I still > cannot reproduce the build issue. Do you have lib32z1 installed? baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-30 21:20 ` Baruch Siach @ 2017-01-30 21:22 ` Jörg Krause 2017-01-30 21:26 ` Baruch Siach 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-01-30 21:22 UTC (permalink / raw) To: buildroot On Mon, 2017-01-30 at 23:20 +0200, Baruch Siach wrote: > Hi J?rg, > > On Mon, Jan 30, 2017 at 08:59:02PM +0100, J?rg Krause wrote: > > On Sun, 2017-01-29 at 23:11 +0200, Baruch Siach wrote: > > > Hi J?rg, > > > > > > On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > > > > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.c > > > > > o.il > > > > > wrote: > > > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause > > > > > > wrote: > > > > > > > Unfortunately I cannot reproduce this issue. Is it a > > > > > > > rpath > > > > > > > issue? > > > > > > > cmake links a test program with host zlib: > > > > > > > > > > Note: I'm not able to reproduce the error either. > > > > > > > > I wonder, what makes the difference to be able to reproduce the > > > > issue. > > > > > > See http://lists.busybox.net/pipermail/buildroot/2017-January/182 > > > 237.html. > > > > I setup a Debian and Scientific Linux system yesterday, but I still > > cannot reproduce the build issue. > > Do you have lib32z1 installed? yes: # pacman -Qi lib32-zlib Name????????????: lib32-zlib Version?????????: 1.2.11-1 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-30 21:22 ` Jörg Krause @ 2017-01-30 21:26 ` Baruch Siach 2017-01-30 21:45 ` Jörg Krause 2017-02-05 22:17 ` Jörg Krause 0 siblings, 2 replies; 29+ messages in thread From: Baruch Siach @ 2017-01-30 21:26 UTC (permalink / raw) To: buildroot Hi J?rg, On Mon, Jan 30, 2017 at 10:22:50PM +0100, J?rg Krause wrote: > On Mon, 2017-01-30 at 23:20 +0200, Baruch Siach wrote: > > On Mon, Jan 30, 2017 at 08:59:02PM +0100, J?rg Krause wrote: > > > On Sun, 2017-01-29 at 23:11 +0200, Baruch Siach wrote: > > > > On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > > > > > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > > > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tkos.c > > > > > > o.il > > > > > > wrote: > > > > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause > > > > > > > wrote: > > > > > > > > Unfortunately I cannot reproduce this issue. Is it a > > > > > > > > rpath > > > > > > > > issue? > > > > > > > > cmake links a test program with host zlib: > > > > > > > > > > > > Note: I'm not able to reproduce the error either. > > > > > > > > > > I wonder, what makes the difference to be able to reproduce the > > > > > issue. > > > > > > > > See http://lists.busybox.net/pipermail/buildroot/2017-January/182 > > > > 237.html. > > > > > > I setup a Debian and Scientific Linux system yesterday, but I still > > > cannot reproduce the build issue. > > > > Do you have lib32z1 installed? > > yes: > > # pacman -Qi lib32-zlib > Name????????????: lib32-zlib > Version?????????: 1.2.11-1 I meant to ask about Debian and the lib32z1 package specifically (not zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. baruch -- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il - ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-30 21:26 ` Baruch Siach @ 2017-01-30 21:45 ` Jörg Krause 2017-02-05 22:17 ` Jörg Krause 1 sibling, 0 replies; 29+ messages in thread From: Jörg Krause @ 2017-01-30 21:45 UTC (permalink / raw) To: buildroot Hi Baruch, On Mon, 2017-01-30 at 23:26 +0200, Baruch Siach wrote: > Hi J?rg, > > On Mon, Jan 30, 2017 at 10:22:50PM +0100, J?rg Krause wrote: > > On Mon, 2017-01-30 at 23:20 +0200, Baruch Siach wrote: > > > On Mon, Jan 30, 2017 at 08:59:02PM +0100, J?rg Krause wrote: > > > > On Sun, 2017-01-29 at 23:11 +0200, Baruch Siach wrote: > > > > > On Sun, Jan 29, 2017 at 09:37:34PM +0100, J?rg Krause wrote: > > > > > > On Thu, 2017-01-26 at 12:04 +0100, Samuel Martin wrote: > > > > > > > On Wed, Jan 25, 2017 at 10:15 PM, Baruch Siach <baruch@tk > > > > > > > os.c > > > > > > > o.il > > > > > > > wrote: > > > > > > > > On Wed, Jan 25, 2017 at 10:05:42PM +0100, J?rg Krause > > > > > > > > wrote: > > > > > > > > > Unfortunately I cannot reproduce this issue. Is it a > > > > > > > > > rpath > > > > > > > > > issue? > > > > > > > > > cmake links a test program with host zlib: > > > > > > > > > > > > > > Note: I'm not able to reproduce the error either. > > > > > > > > > > > > I wonder, what makes the difference to be able to reproduce > > > > > > the > > > > > > issue. > > > > > > > > > > See http://lists.busybox.net/pipermail/buildroot/2017-January > > > > > /182 > > > > > 237.html. > > > > > > > > I setup a Debian and Scientific Linux system yesterday, but I > > > > still > > > > cannot reproduce the build issue. > > > > > > Do you have lib32z1 installed? > > > > yes: > > > > # pacman -Qi lib32-zlib > > Name????????????: lib32-zlib > > Version?????????: 1.2.11-1 > > I meant to ask about Debian and the lib32z1 package specifically > (not? > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. > No, lib32z1 was not installed on my fresh Debian system. Thanks for this! Now I am able to reproduce the issue. J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-01-30 21:26 ` Baruch Siach 2017-01-30 21:45 ` Jörg Krause @ 2017-02-05 22:17 ` Jörg Krause 2017-02-06 11:06 ` Thomas Petazzoni 1 sibling, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-02-05 22:17 UTC (permalink / raw) To: buildroot Hi, On Mon, 2017-01-30 at 23:26 +0200, Baruch Siach wrote: > Hi J?rg, > [snip] > > I meant to ask about Debian and the lib32z1 package specifically > (not? > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. I reported the issue on the CMake mailing list [1]. The issue is that the host rpath is used when cross-compiling a simple test program generated by the check_symbol_exists() macro. I had no success in disabling the rpath for any of the check_*_macros(). As I am not a CMake expert, it's quite possible that I missed something. Has anyone an idea how to fix this issue? [1] https://cmake.org/pipermail/cmake/2017-February/064970.html ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-05 22:17 ` Jörg Krause @ 2017-02-06 11:06 ` Thomas Petazzoni 2017-02-06 16:52 ` Samuel Martin 0 siblings, 1 reply; 29+ messages in thread From: Thomas Petazzoni @ 2017-02-06 11:06 UTC (permalink / raw) To: buildroot Hello, On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: > > I meant to ask about Debian and the lib32z1 package specifically > > (not? > > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. > > I reported the issue on the CMake mailing list [1]. The issue is that > the host rpath is used when cross-compiling a simple test program > generated by the check_symbol_exists() macro. I had no success in > disabling the rpath for any of the check_*_macros(). > > As I am not a CMake expert, it's quite possible that I missed > something. Has anyone an idea how to fix this issue? > > [1] https://cmake.org/pipermail/cmake/2017-February/064970.html I've added Samuel in Cc. He is our CMake guy :) Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 11:06 ` Thomas Petazzoni @ 2017-02-06 16:52 ` Samuel Martin 2017-02-06 17:43 ` Jörg Krause 0 siblings, 1 reply; 29+ messages in thread From: Samuel Martin @ 2017-02-06 16:52 UTC (permalink / raw) To: buildroot Hi Jorg, all, On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote: > Hello, > > On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: > >> > I meant to ask about Debian and the lib32z1 package specifically >> > (not >> > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. >> >> I reported the issue on the CMake mailing list [1]. The issue is that >> the host rpath is used when cross-compiling a simple test program >> generated by the check_symbol_exists() macro. I had no success in >> disabling the rpath for any of the check_*_macros(). >> >> As I am not a CMake expert, it's quite possible that I missed >> something. Has anyone an idea how to fix this issue? >> >> [1] https://cmake.org/pipermail/cmake/2017-February/064970.html > > I've added Samuel in Cc. He is our CMake guy :) I had a look at mbedtls cmake code. It's definitely not really the usual way to use cmake. They do not use cmake primitives to generate the config.h file [1] or check for pthread [2]... :( So, this forces us to either workaround this in buildroot's *.mk files (like you did), or rework the mbedtls cmake code. I submitted few patches to improve the situation (see PR [3]), and hopefully get rid the hooks sooner or later. [1] https://cmake.org/cmake/help/v3.7/command/configure_file.html [2] https://cmake.org/cmake/help/v3.7/module/FindThreads.html [3] https://github.com/ARMmbed/mbedtls/pull/791 Regards, -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 16:52 ` Samuel Martin @ 2017-02-06 17:43 ` Jörg Krause 2017-02-06 17:53 ` Samuel Martin 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-02-06 17:43 UTC (permalink / raw) To: buildroot Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin <s.martin49@gmail.com>: >Hi Jorg, all, > >On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni ><thomas.petazzoni@free-electrons.com> wrote: >> Hello, >> >> On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: >> >>> > I meant to ask about Debian and the lib32z1 package specifically >>> > (not >>> > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. >>> >>> I reported the issue on the CMake mailing list [1]. The issue is >that >>> the host rpath is used when cross-compiling a simple test program >>> generated by the check_symbol_exists() macro. I had no success in >>> disabling the rpath for any of the check_*_macros(). >>> >>> As I am not a CMake expert, it's quite possible that I missed >>> something. Has anyone an idea how to fix this issue? >>> >>> [1] https://cmake.org/pipermail/cmake/2017-February/064970.html >> >> I've added Samuel in Cc. He is our CMake guy :) > >I had a look at mbedtls cmake code. >It's definitely not really the usual way to use cmake. > >They do not use cmake primitives to generate the config.h file [1] or >check for pthread [2]... :( >So, this forces us to either workaround this in buildroot's *.mk files >(like you did), or rework the mbedtls cmake code. >I submitted few patches to improve the situation (see PR [3]), and >hopefully get rid the hooks sooner or later. I see! Many thanks for the investigativ work! Maybe I am wrong, but this has no affect on the bctoolbox build issue, right? >[1] https://cmake.org/cmake/help/v3.7/command/configure_file.html >[2] https://cmake.org/cmake/help/v3.7/module/FindThreads.html >[3] https://github.com/ARMmbed/mbedtls/pull/791 -- J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 17:43 ` Jörg Krause @ 2017-02-06 17:53 ` Samuel Martin 2017-02-06 17:59 ` Jörg Krause 0 siblings, 1 reply; 29+ messages in thread From: Samuel Martin @ 2017-02-06 17:53 UTC (permalink / raw) To: buildroot On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause <joerg.krause@embedded.rocks> wrote: > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin <s.martin49@gmail.com>: >>Hi Jorg, all, >> >>On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni >><thomas.petazzoni@free-electrons.com> wrote: >>> Hello, >>> >>> On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: >>> >>>> > I meant to ask about Debian and the lib32z1 package specifically >>>> > (not >>>> > zlib1g:i386). This package installs 32bit libz.so.1 in /usr/lib32. >>>> >>>> I reported the issue on the CMake mailing list [1]. The issue is >>that >>>> the host rpath is used when cross-compiling a simple test program >>>> generated by the check_symbol_exists() macro. I had no success in >>>> disabling the rpath for any of the check_*_macros(). >>>> >>>> As I am not a CMake expert, it's quite possible that I missed >>>> something. Has anyone an idea how to fix this issue? >>>> >>>> [1] https://cmake.org/pipermail/cmake/2017-February/064970.html >>> >>> I've added Samuel in Cc. He is our CMake guy :) >> >>I had a look at mbedtls cmake code. >>It's definitely not really the usual way to use cmake. >> >>They do not use cmake primitives to generate the config.h file [1] or >>check for pthread [2]... :( >>So, this forces us to either workaround this in buildroot's *.mk files >>(like you did), or rework the mbedtls cmake code. >>I submitted few patches to improve the situation (see PR [3]), and >>hopefully get rid the hooks sooner or later. > > I see! Many thanks for the investigativ work! > > Maybe I am wrong, but this has no affect on the bctoolbox build issue, right? Right, to improve the bctoolbox case, mbedtls should generate and install its own mbedtls-config.cmake according to its configuration; so that bctoolbox can leverage it in its own cmake code. This is the next step on mbedtls code ;-) > >>[1] https://cmake.org/cmake/help/v3.7/command/configure_file.html >>[2] https://cmake.org/cmake/help/v3.7/module/FindThreads.html >>[3] https://github.com/ARMmbed/mbedtls/pull/791 > > > -- > J?rg -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 17:53 ` Samuel Martin @ 2017-02-06 17:59 ` Jörg Krause 2017-02-06 18:14 ` Samuel Martin 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-02-06 17:59 UTC (permalink / raw) To: buildroot Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@gmail.com>: >On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause ><joerg.krause@embedded.rocks> wrote: >> >> >> Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin ><s.martin49@gmail.com>: >>>Hi Jorg, all, >>> >>>On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni >>><thomas.petazzoni@free-electrons.com> wrote: >>>> Hello, >>>> >>>> On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: >>>> >>>>> > I meant to ask about Debian and the lib32z1 package specifically >>>>> > (not >>>>> > zlib1g:i386). This package installs 32bit libz.so.1 in >/usr/lib32. >>>>> >>>>> I reported the issue on the CMake mailing list [1]. The issue is >>>that >>>>> the host rpath is used when cross-compiling a simple test program >>>>> generated by the check_symbol_exists() macro. I had no success in >>>>> disabling the rpath for any of the check_*_macros(). >>>>> >>>>> As I am not a CMake expert, it's quite possible that I missed >>>>> something. Has anyone an idea how to fix this issue? >>>>> >>>>> [1] https://cmake.org/pipermail/cmake/2017-February/064970.html >>>> >>>> I've added Samuel in Cc. He is our CMake guy :) >>> >>>I had a look at mbedtls cmake code. >>>It's definitely not really the usual way to use cmake. >>> >>>They do not use cmake primitives to generate the config.h file [1] or >>>check for pthread [2]... :( >>>So, this forces us to either workaround this in buildroot's *.mk >files >>>(like you did), or rework the mbedtls cmake code. >>>I submitted few patches to improve the situation (see PR [3]), and >>>hopefully get rid the hooks sooner or later. >> >> I see! Many thanks for the investigativ work! >> >> Maybe I am wrong, but this has no affect on the bctoolbox build >issue, right? > >Right, to improve the bctoolbox case, mbedtls should generate and >install its own mbedtls-config.cmake according to its configuration; >so that bctoolbox can leverage it in its own cmake code. This is the >next step on mbedtls code ;-) Thanks! Do you have any idea why CMake adds the rpath when using check_symbol_exists() in a cross-compilation environment? I reported the issue on the CMake mailing list... >> >>>[1] https://cmake.org/cmake/help/v3.7/command/configure_file.html >>>[2] https://cmake.org/cmake/help/v3.7/module/FindThreads.html >>>[3] https://github.com/ARMmbed/mbedtls/pull/791 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 17:59 ` Jörg Krause @ 2017-02-06 18:14 ` Samuel Martin 2017-02-06 19:24 ` Jörg Krause ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Samuel Martin @ 2017-02-06 18:14 UTC (permalink / raw) To: buildroot On Mon, Feb 6, 2017 at 6:59 PM, J?rg Krause <joerg.krause@embedded.rocks> wrote: > > > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@gmail.com>: >>On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause >><joerg.krause@embedded.rocks> wrote: >>> >>> >>> Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin >><s.martin49@gmail.com>: >>>>Hi Jorg, all, >>>> >>>>On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni >>>><thomas.petazzoni@free-electrons.com> wrote: >>>>> Hello, >>>>> >>>>> On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: >>>>> >>>>>> > I meant to ask about Debian and the lib32z1 package specifically >>>>>> > (not >>>>>> > zlib1g:i386). This package installs 32bit libz.so.1 in >>/usr/lib32. >>>>>> >>>>>> I reported the issue on the CMake mailing list [1]. The issue is >>>>that >>>>>> the host rpath is used when cross-compiling a simple test program >>>>>> generated by the check_symbol_exists() macro. I had no success in >>>>>> disabling the rpath for any of the check_*_macros(). >>>>>> >>>>>> As I am not a CMake expert, it's quite possible that I missed >>>>>> something. Has anyone an idea how to fix this issue? >>>>>> >>>>>> [1] https://cmake.org/pipermail/cmake/2017-February/064970.html >>>>> >>>>> I've added Samuel in Cc. He is our CMake guy :) >>>> [...] > Do you have any idea why CMake adds the rpath when using check_symbol_exists() in a cross-compilation environment? I reported the issue on the CMake mailing list... I saw your report. Not a clue so far. I do have /usr/lib32/libz.so.1 (/usr/lib32/libz.so.1 -> libz.so.1.2.11) on my system as well, but I'm not able to reproduce the error (the cmake-3.7.2 from my host archlinux picks the right lib from the sysroot :-/). -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 18:14 ` Samuel Martin @ 2017-02-06 19:24 ` Jörg Krause 2017-02-06 21:12 ` Jörg Krause 2017-02-06 23:38 ` Jörg Krause 2 siblings, 0 replies; 29+ messages in thread From: Jörg Krause @ 2017-02-06 19:24 UTC (permalink / raw) To: buildroot On Mon, 2017-02-06 at 19:14 +0100, Samuel Martin wrote: > On Mon, Feb 6, 2017 at 6:59 PM, J?rg Krause <joerg.krause@embedded.ro > cks> wrote: > > > > > > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@g > > mail.com>: > > > On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause > > > <joerg.krause@embedded.rocks> wrote: > > > > > > > > > > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin > > > > > > <s.martin49@gmail.com>: > > > > > Hi Jorg, all, > > > > > > > > > > On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni > > > > > <thomas.petazzoni@free-electrons.com> wrote: > > > > > > Hello, > > > > > > > > > > > > On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: > > > > > > > > > > > > > > I meant to ask about Debian and the lib32z1 package > > > > > > > > specifically > > > > > > > > (not > > > > > > > > zlib1g:i386). This package installs 32bit libz.so.1 in > > > > > > /usr/lib32. > > > > > > > > > > > > > > I reported the issue on the CMake mailing list [1]. The > > > > > > > issue is > > > > > > > > > > that > > > > > > > the host rpath is used when cross-compiling a simple test > > > > > > > program > > > > > > > generated by the check_symbol_exists() macro. I had no > > > > > > > success in > > > > > > > disabling the rpath for any of the check_*_macros(). > > > > > > > > > > > > > > As I am not a CMake expert, it's quite possible that I > > > > > > > missed > > > > > > > something. Has anyone an idea how to fix this issue? > > > > > > > > > > > > > > [1] https://cmake.org/pipermail/cmake/2017-February/06497 > > > > > > > 0.html > > > > > > > > > > > > I've added Samuel in Cc. He is our CMake guy :) > > [...] > > > Do you have any idea why CMake adds the rpath when using > > check_symbol_exists() in a cross-compilation environment? I > > reported the issue on the CMake mailing list... > > I saw your report. > Not a clue so far. > I do have /usr/lib32/libz.so.1 (/usr/lib32/libz.so.1 -> > libz.so.1.2.11) on my system as well, but I'm not able to reproduce > the error (the cmake-3.7.2 from my host archlinux picks the right lib > from the sysroot :-/). I am not able to reproduce the issue on my Arch Linux host, too. But, I am able to reproduce it on a Debian host. Despite the reproducability, am I right that rpath should not be passed to the cross-linker by CMake when compiling and linking a test program as it is done when using check_symbol_exists()? Only the sysroot flag should be passed to the cross-linker, right? J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 18:14 ` Samuel Martin 2017-02-06 19:24 ` Jörg Krause @ 2017-02-06 21:12 ` Jörg Krause 2017-02-06 23:38 ` Jörg Krause 2 siblings, 0 replies; 29+ messages in thread From: Jörg Krause @ 2017-02-06 21:12 UTC (permalink / raw) To: buildroot On Mon, 2017-02-06 at 19:14 +0100, Samuel Martin wrote: > On Mon, Feb 6, 2017 at 6:59 PM, J?rg Krause <joerg.krause@embedded.ro > cks> wrote: > > > > > > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@g > > mail.com>: > > > On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause > > > <joerg.krause@embedded.rocks> wrote: > > > > > > > > > > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin > > > > > > <s.martin49@gmail.com>: > > > > > Hi Jorg, all, > > > > > > > > > > On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni > > > > > <thomas.petazzoni@free-electrons.com> wrote: > > > > > > Hello, > > > > > > > > > > > > On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: > > > > > > > > > > > > > > I meant to ask about Debian and the lib32z1 package > > > > > > > > specifically > > > > > > > > (not > > > > > > > > zlib1g:i386). This package installs 32bit libz.so.1 in > > > > > > /usr/lib32. > > > > > > > > > > > > > > I reported the issue on the CMake mailing list [1]. The > > > > > > > issue is > > > > > > > > > > that > > > > > > > the host rpath is used when cross-compiling a simple test > > > > > > > program > > > > > > > generated by the check_symbol_exists() macro. I had no > > > > > > > success in > > > > > > > disabling the rpath for any of the check_*_macros(). > > > > > > > > > > > > > > As I am not a CMake expert, it's quite possible that I > > > > > > > missed > > > > > > > something. Has anyone an idea how to fix this issue? > > > > > > > > > > > > > > [1] https://cmake.org/pipermail/cmake/2017-February/06497 > > > > > > > 0.html > > > > > > > > > > > > I've added Samuel in Cc. He is our CMake guy :) > > [...] > > > Do you have any idea why CMake adds the rpath when using > > check_symbol_exists() in a cross-compilation environment? I > > reported the issue on the CMake mailing list... > > I saw your report. > Not a clue so far. > I do have /usr/lib32/libz.so.1 (/usr/lib32/libz.so.1 -> > libz.so.1.2.11) on my system as well, but I'm not able to reproduce > the error (the cmake-3.7.2 from my host archlinux picks the right lib > from the sysroot :-/). I tested with CMake 3.0.2 on the Debian host and CMake does not pass rpath to the cross-linker in this version. J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 18:14 ` Samuel Martin 2017-02-06 19:24 ` Jörg Krause 2017-02-06 21:12 ` Jörg Krause @ 2017-02-06 23:38 ` Jörg Krause 2017-02-07 11:28 ` Samuel Martin 2 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-02-06 23:38 UTC (permalink / raw) To: buildroot Hi Samuel, On Mon, 2017-02-06 at 19:14 +0100, Samuel Martin wrote: > On Mon, Feb 6, 2017 at 6:59 PM, J?rg Krause <joerg.krause@embedded.ro > cks> wrote: > > > > > > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@g > > mail.com>: > > > On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause > > > <joerg.krause@embedded.rocks> wrote: > > > > > > > > > > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin > > > > > > <s.martin49@gmail.com>: > > > > > Hi Jorg, all, > > > > > > > > > > On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni > > > > > <thomas.petazzoni@free-electrons.com> wrote: > > > > > > Hello, > > > > > > > > > > > > On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: > > > > > > > > > > > > > > I meant to ask about Debian and the lib32z1 package > > > > > > > > specifically > > > > > > > > (not > > > > > > > > zlib1g:i386). This package installs 32bit libz.so.1 in > > > > > > /usr/lib32. > > > > > > > > > > > > > > I reported the issue on the CMake mailing list [1]. The > > > > > > > issue is > > > > > > > > > > that > > > > > > > the host rpath is used when cross-compiling a simple test > > > > > > > program > > > > > > > generated by the check_symbol_exists() macro. I had no > > > > > > > success in > > > > > > > disabling the rpath for any of the check_*_macros(). > > > > > > > > > > > > > > As I am not a CMake expert, it's quite possible that I > > > > > > > missed > > > > > > > something. Has anyone an idea how to fix this issue? > > > > > > > > > > > > > > [1] https://cmake.org/pipermail/cmake/2017-February/06497 > > > > > > > 0.html > > > > > > > > > > > > I've added Samuel in Cc. He is our CMake guy :) > > [...] > > > Do you have any idea why CMake adds the rpath when using > > check_symbol_exists() in a cross-compilation environment? I > > reported the issue on the CMake mailing list... > > I saw your report. > Not a clue so far. > I do have /usr/lib32/libz.so.1 (/usr/lib32/libz.so.1 -> > libz.so.1.2.11) on my system as well, but I'm not able to reproduce > the error (the cmake-3.7.2 from my host archlinux picks the right lib > from the sysroot :-/). Version 3.6.3 works, too. So, I did a git bisect. The rpath issue was introduced in "Teach find_library and find_package to search lib32 paths" [1]. Any ideas how to fix this? [1] https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3 cbbcf9a6cce85a16681 J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-06 23:38 ` Jörg Krause @ 2017-02-07 11:28 ` Samuel Martin 2017-02-07 13:00 ` Jörg Krause 0 siblings, 1 reply; 29+ messages in thread From: Samuel Martin @ 2017-02-07 11:28 UTC (permalink / raw) To: buildroot J?rg, all, On Tue, Feb 7, 2017 at 12:38 AM, J?rg Krause <joerg.krause@embedded.rocks> wrote: > Hi Samuel, > > On Mon, 2017-02-06 at 19:14 +0100, Samuel Martin wrote: >> On Mon, Feb 6, 2017 at 6:59 PM, J?rg Krause <joerg.krause@embedded.ro >> cks> wrote: >> > >> > >> > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49@g >> > mail.com>: >> > > On Mon, Feb 6, 2017 at 6:43 PM, J?rg Krause >> > > <joerg.krause@embedded.rocks> wrote: >> > > > >> > > > >> > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin >> > > >> > > <s.martin49@gmail.com>: >> > > > > Hi Jorg, all, >> > > > > >> > > > > On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni >> > > > > <thomas.petazzoni@free-electrons.com> wrote: >> > > > > > Hello, >> > > > > > >> > > > > > On Sun, 05 Feb 2017 23:17:17 +0100, J?rg Krause wrote: >> > > > > > >> > > > > > > > I meant to ask about Debian and the lib32z1 package >> > > > > > > > specifically >> > > > > > > > (not >> > > > > > > > zlib1g:i386). This package installs 32bit libz.so.1 in >> > > >> > > /usr/lib32. >> > > > > > > >> > > > > > > I reported the issue on the CMake mailing list [1]. The >> > > > > > > issue is >> > > > > >> > > > > that >> > > > > > > the host rpath is used when cross-compiling a simple test >> > > > > > > program >> > > > > > > generated by the check_symbol_exists() macro. I had no >> > > > > > > success in >> > > > > > > disabling the rpath for any of the check_*_macros(). >> > > > > > > >> > > > > > > As I am not a CMake expert, it's quite possible that I >> > > > > > > missed >> > > > > > > something. Has anyone an idea how to fix this issue? >> > > > > > > >> > > > > > > [1] https://cmake.org/pipermail/cmake/2017-February/06497 >> > > > > > > 0.html >> > > > > > >> > > > > > I've added Samuel in Cc. He is our CMake guy :) >> >> [...] >> >> > Do you have any idea why CMake adds the rpath when using >> > check_symbol_exists() in a cross-compilation environment? I >> > reported the issue on the CMake mailing list... >> >> I saw your report. >> Not a clue so far. >> I do have /usr/lib32/libz.so.1 (/usr/lib32/libz.so.1 -> >> libz.so.1.2.11) on my system as well, but I'm not able to reproduce >> the error (the cmake-3.7.2 from my host archlinux picks the right lib >> from the sysroot :-/). > > Version 3.6.3 works, too. So, I did a git bisect. The rpath issue was > introduced in "Teach find_library and find_package to search lib32 > paths" [1]. Thanks for the investigation! > > Any ideas how to fix this? Not so far :-/ Could you apply this change, run (from an already populated build tree, no need to restart the build from scratch): $ make mbedtls-dirclean mbedtls-configure 2>&1 | tee mbedtls-configure.log and pastebin/share the mbedtls-configure.log file? > > [1] https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3 > cbbcf9a6cce85a16681 > > J?rg TIA, -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-07 11:28 ` Samuel Martin @ 2017-02-07 13:00 ` Jörg Krause 2017-02-07 13:29 ` Samuel Martin 0 siblings, 1 reply; 29+ messages in thread From: Jörg Krause @ 2017-02-07 13:00 UTC (permalink / raw) To: buildroot Hi Samuel, On Tue, 2017-02-07 at 12:28 +0100, Samuel Martin wrote: > J?rg, all, > > On Tue, Feb 7, 2017 at 12:38 AM, J?rg Krause > <joerg.krause@embedded.rocks> wrote: > > Hi Samuel, > > [snip] > > > > Version 3.6.3 works, too. So, I did a git bisect. The rpath issue > > was > > introduced in "Teach find_library and find_package to search lib32 > > paths" [1]. > > Thanks for the investigation! > > > > > Any ideas how to fix this? > > Not so far :-/ Ray Donnely proposed a potential fix for this issue [1] on the CMake mailing list. I have not tried the patch so far. > Could you apply this change, run (from an already populated build > tree, no need to restart the build from scratch): > ? $ make mbedtls-dirclean mbedtls-configure 2>&1 | tee mbedtls- > configure.log > > and pastebin/share the mbedtls-configure.log file? Sorry, but I don't understand. Which change do you mean? Should I run this on the Debian (bctoolbox build error is reproducable) or the Arch (bctoolbox build error is not reproducable) host? Which CMake version should I use? [1] https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fda ab7d8b812d503f67f8cef69532 J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-07 13:00 ` Jörg Krause @ 2017-02-07 13:29 ` Samuel Martin 2017-02-07 19:07 ` Jörg Krause 2017-02-09 20:02 ` Jörg Krause 0 siblings, 2 replies; 29+ messages in thread From: Samuel Martin @ 2017-02-07 13:29 UTC (permalink / raw) To: buildroot On Tue, Feb 7, 2017 at 2:00 PM, J?rg Krause <joerg.krause@embedded.rocks> wrote: > Hi Samuel, > > On Tue, 2017-02-07 at 12:28 +0100, Samuel Martin wrote: >> J?rg, all, >> >> On Tue, Feb 7, 2017 at 12:38 AM, J?rg Krause >> <joerg.krause@embedded.rocks> wrote: >> > Hi Samuel, >> > > > [snip] > >> > >> > Version 3.6.3 works, too. So, I did a git bisect. The rpath issue >> > was >> > introduced in "Teach find_library and find_package to search lib32 >> > paths" [1]. >> >> Thanks for the investigation! >> >> > >> > Any ideas how to fix this? >> >> Not so far :-/ > > Ray Donnely proposed a potential fix for this issue [1] on the CMake > mailing list. I have not tried the patch so far. Good to know CMake folks are already on this issue. > >> Could you apply this change, run (from an already populated build >> tree, no need to restart the build from scratch): >> $ make mbedtls-dirclean mbedtls-configure 2>&1 | tee mbedtls- >> configure.log >> >> and pastebin/share the mbedtls-configure.log file? > > Sorry, but I don't understand. Which change do you mean? Should I run > this on the Debian (bctoolbox build error is reproducable) or the Arch > (bctoolbox build error is not reproducable) host? Which CMake version > should I use? Sorry, I forgot the url :s this one: http://code.bulix.org/pkabso-113323 > > [1] https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fda > ab7d8b812d503f67f8cef69532 > > J?rg -- Samuel ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-07 13:29 ` Samuel Martin @ 2017-02-07 19:07 ` Jörg Krause 2017-02-09 20:02 ` Jörg Krause 1 sibling, 0 replies; 29+ messages in thread From: Jörg Krause @ 2017-02-07 19:07 UTC (permalink / raw) To: buildroot Hi Samuel, On Tue, 2017-02-07 at 14:29 +0100, Samuel Martin wrote: > On Tue, Feb 7, 2017 at 2:00 PM, J?rg Krause <joerg.krause@embedded.ro > cks> wrote: > > Hi Samuel, > > > > On Tue, 2017-02-07 at 12:28 +0100, Samuel Martin wrote: > > > J?rg, all, > > > > > > On Tue, Feb 7, 2017 at 12:38 AM, J?rg Krause > > > <joerg.krause@embedded.rocks> wrote: > > > > Hi Samuel, > > > > > > > > [snip] > > > > > > > > > > Version 3.6.3 works, too. So, I did a git bisect. The rpath > > > > issue > > > > was > > > > introduced in "Teach find_library and find_package to search > > > > lib32 > > > > paths" [1]. > > > > > > Thanks for the investigation! > > > > > > > > > > > Any ideas how to fix this? > > > > > > Not so far :-/ > > > > Ray Donnely proposed a potential fix for this issue [1] on the > > CMake > > mailing list. I have not tried the patch so far. > > Good to know CMake folks are already on this issue. > > > > > > Could you apply this change, run (from an already populated build > > > tree, no need to restart the build from scratch): > > > ? $ make mbedtls-dirclean mbedtls-configure 2>&1 | tee mbedtls- > > > configure.log > > > > > > and pastebin/share the mbedtls-configure.log file? > > > > Sorry, but I don't understand. Which change do you mean? Should I > > run > > this on the Debian (bctoolbox build error is reproducable) or the > > Arch > > (bctoolbox build error is not reproducable) host? Which CMake > > version > > should I use? > > Sorry, I forgot the url :s this one: > http://code.bulix.org/pkabso-113323 This is the link to the output: http://code.bulix.org/gu6jeh-113374 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 2017-02-07 13:29 ` Samuel Martin 2017-02-07 19:07 ` Jörg Krause @ 2017-02-09 20:02 ` Jörg Krause 1 sibling, 0 replies; 29+ messages in thread From: Jörg Krause @ 2017-02-09 20:02 UTC (permalink / raw) To: buildroot Hi, On Tue, 2017-02-07 at 14:29 +0100, Samuel Martin wrote: > On Tue, Feb 7, 2017 at 2:00 PM, J?rg Krause <joerg.krause@embedded.ro > cks> wrote: > > Hi Samuel, > > > > On Tue, 2017-02-07 at 12:28 +0100, Samuel Martin wrote: > > > J?rg, all, > > > > > > On Tue, Feb 7, 2017 at 12:38 AM, J?rg Krause > > > <joerg.krause@embedded.rocks> wrote: > > > > Hi Samuel, > > > > > > > > [snip] > > > > > > > > > > Version 3.6.3 works, too. So, I did a git bisect. The rpath > > > > issue > > > > was > > > > introduced in "Teach find_library and find_package to search > > > > lib32 > > > > paths" [1]. > > > > > > Thanks for the investigation! > > > > > > > > > > > Any ideas how to fix this? > > > > > > Not so far :-/ > > > > Ray Donnely proposed a potential fix for this issue [1] on the > > CMake > > mailing list. I have not tried the patch so far. > > Good to know CMake folks are already on this issue. I had a closer look on why the rpath '/usr/lib32' is used in CMake 3.7. This upstream commit [1] adds a property `FIND_LIBRARY_USE_LIB32_PATHS` which is set to TRUE for the Linux platform [2]. This changes the behavior of `find_library()`. Before the commit `/sysroot/usr/lib` was found as library path, but now it's `/sysroot/usr/lib32`. When determining the runtime search path, CMake compares the pathes found by `find_library()` with a list of implicit runtime pathes. This list contains `/sysroot/usr/lib` but not `/sysroot/usr/lib32`. If the library path found by `find_library()` matches a search path from the list of implicit runtime pathes it is dropped, otherwise it is added to rpath after removing the `/sysroot` path. As the implicit runtime search pathes does not contain `/sysroot/usr/lib32` the rpath is set to `/usr/lib32`. Note, that this is true not only for bctoolbox but for all CMake packages! The behavior of determining the runtime path is controlled by the property `FIND_LIBRARY_USE_LIB32_PATHS`. As already mentioned, the value is set to `TRUE` for the Linux platfrom. I tried to overwrite the property in the toolchain file, without any luck. Another possibility might be to add `/sysroot/usr/lib32` to the list of implicit link directories, but using `CMAKE_C_IMPLICIT_LINK_DIRECTORIES` in the toolchain file did not work for me. An approach which worked for me was to remove the `CMAKE_SYSTEM_NAME` setting from the toolchain file. This way, I was able to set the `FIND_LIBRARY_USE_LIB32_PATHS` property to `FALSE` and `/usr/lib32` was not set as rpath anymore. Samuel, do you have any idea how to set the property `FIND_LIBRARY_USE_LIB32_PATHS` without removing `CMAKE_SYSTEM_NAME` from the toolchain file? Or is there any other solution? [1] https://gitlab.kitware.com/cmake/cmake/commit/896ad251de49f167f4ce3 cbbcf9a6cce85a16681 [2] https://gitlab.kitware.com/cmake/cmake/blob/896ad251de49f167f4ce3cb bcf9a6cce85a16681/Modules/Platform/Linux.cmake#L56 J?rg ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2017-02-09 20:02 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-25 7:30 [Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24 Thomas Petazzoni 2017-01-25 21:05 ` Jörg Krause 2017-01-25 21:15 ` Baruch Siach 2017-01-26 11:04 ` Samuel Martin 2017-01-26 11:11 ` Baruch Siach 2017-01-26 11:14 ` Jörg Krause 2017-01-26 11:28 ` Baruch Siach 2017-01-29 20:37 ` Jörg Krause 2017-01-29 21:11 ` Baruch Siach 2017-01-30 19:59 ` Jörg Krause 2017-01-30 21:20 ` Baruch Siach 2017-01-30 21:22 ` Jörg Krause 2017-01-30 21:26 ` Baruch Siach 2017-01-30 21:45 ` Jörg Krause 2017-02-05 22:17 ` Jörg Krause 2017-02-06 11:06 ` Thomas Petazzoni 2017-02-06 16:52 ` Samuel Martin 2017-02-06 17:43 ` Jörg Krause 2017-02-06 17:53 ` Samuel Martin 2017-02-06 17:59 ` Jörg Krause 2017-02-06 18:14 ` Samuel Martin 2017-02-06 19:24 ` Jörg Krause 2017-02-06 21:12 ` Jörg Krause 2017-02-06 23:38 ` Jörg Krause 2017-02-07 11:28 ` Samuel Martin 2017-02-07 13:00 ` Jörg Krause 2017-02-07 13:29 ` Samuel Martin 2017-02-07 19:07 ` Jörg Krause 2017-02-09 20:02 ` Jörg Krause
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.