[Buildroot] [autobuild.buildroot.net] Build results for 2017-01-24

[Jörg Krause]

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 at embedded.ro
> cks> wrote:
> > 
> > 
> > Am 6. Februar 2017 18:53:56 MEZ schrieb Samuel Martin <s.martin49 at g
> > mail.com>:
> > > On Mon, Feb 6, 2017 at 6:43 PM, Jörg Krause
> > > <joerg.krause at embedded.rocks> wrote:
> > > > 
> > > > 
> > > > Am 6. Februar 2017 17:52:33 MEZ schrieb Samuel Martin
> > > 
> > > <s.martin49 at gmail.com>:
> > > > > Hi Jorg, all,
> > > > > 
> > > > > On Mon, Feb 6, 2017 at 12:06 PM, Thomas Petazzoni
> > > > > <thomas.petazzoni at 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