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

[Samuel Martin <s.martin49@gmail.com>]

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