All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.