Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/28/2017 08:22 AM, Brad King wrote:
>> 2) Make sure, in case lib32 is a symlink, to follow the symlink.
> 
> I was thinking the same thing.  The lib => lib32 search path conversion
> should just be skipped if lib32 is a symlink back to lib.

For reference, I opened an issue for this part of the work [1].

-Brad


[1] https://gitlab.kitware.com/cmake/cmake/issues/16687

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Jörg Krause]

On Tue, 2017-02-28 at 08:22 -0500, Brad King wrote:
> On 02/28/2017 05:25 AM, Jörg Krause wrote:
> > Buildroot does not have any problems with searching for libraries
> > in
> > lib32. It does have a problem with having a host rpath used for
> > linking
> > with libraries.
> 
> From your description we are not adding a host rpath.  It's coming
> from
> /sysroot/usr/lib32 which is converted to /usr/lib32 by stripping the
> sysroot.  If you were to run the binary purely in the target
> environment
> then it would find the library in the target's /usr/lib32.  It is not
> clear to my how the binary is being run on the host, but doing so
> uses
> the host's /usr/lib32 because the binary was built for the target.
> 
> > From my understanding, there are some possibilities to fix this
> > issue:
> > 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is
> > enabled,
> > and only search in lib32 in case the target is not found in lib.
> 
> The purpose of that features is so on a 64-bit system with 64-bit
> libs
> in `lib` and 32-bit libs in `lib32` that we find the latter when the
> target architecture is 32 bit.
> 
> > 2) Make sure, in case lib32 is a symlink, to follow the symlink.
> 
> I was thinking the same thing.  The lib => lib32 search path
> conversion
> should just be skipped if lib32 is a symlink back to lib.
> 
> > 3) Make sure, in case lib32 is a symlink to lib and is not included
> > in
> > the linker search paths, to add it to the implicit runtime search
> > paths.
> 
> Yes, the issue I filed is about handling symlinks when comparing
> rpath
> entries to the list of implicit directories.
> 
> I encourage you to sign up on gitlab.kitware.com to join discussion
> in
> that issue.

I move the discussion to the gitlab issue: https://gitlab.kitware.com/c
make/cmake/issues/16682

Jörg
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/27/2017 08:11 PM, Ray Donnelly wrote:
>> CMake passes the host rpath to the linker
> 
> CMake does this because it isn't *asking* the linker, it's making
> assumptions instead (and adding some predefined values like
> `/usr/lib32`). If we just ask the linker instead then everything
> should work just fine (I am ignore linkers that cannot tell us here
> like Apple's ld64. I'm not sure how to tackle that one yet).

The /usr/lib32 path is not coming from any assumption or from guessing
about the linker's rpath.  It is appearing because we add to the rpath
directories in which shared libraries appear that we include in our link.
When find_library discovers /usr/lib32/libfoo.so, and we link to that
library, then we add /usr/lib32 to the rpath if it is not in the implicit
list.  If we were to ask the linker what its rpath is it would say
"/usr/lib" and then we would say "/usr/lib32 != /usr/lib" and add it
anyway.  Jörg's problem is about this lack of symlink recognition, and
that is the issue I filed.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/28/2017 05:25 AM, Jörg Krause wrote:
> Buildroot does not have any problems with searching for libraries in
> lib32. It does have a problem with having a host rpath used for linking
> with libraries.

From your description we are not adding a host rpath.  It's coming from
/sysroot/usr/lib32 which is converted to /usr/lib32 by stripping the
sysroot.  If you were to run the binary purely in the target environment
then it would find the library in the target's /usr/lib32.  It is not
clear to my how the binary is being run on the host, but doing so uses
the host's /usr/lib32 because the binary was built for the target.

> From my understanding, there are some possibilities to fix this issue:
> 1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is enabled,
> and only search in lib32 in case the target is not found in lib.

The purpose of that features is so on a 64-bit system with 64-bit libs
in `lib` and 32-bit libs in `lib32` that we find the latter when the
target architecture is 32 bit.

> 2) Make sure, in case lib32 is a symlink, to follow the symlink.

I was thinking the same thing.  The lib => lib32 search path conversion
should just be skipped if lib32 is a symlink back to lib.

> 3) Make sure, in case lib32 is a symlink to lib and is not included in
> the linker search paths, to add it to the implicit runtime search
> paths.

Yes, the issue I filed is about handling symlinks when comparing rpath
entries to the list of implicit directories.

I encourage you to sign up on gitlab.kitware.com to join discussion in
that issue.

Thanks,
-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Jörg Krause]

On Mon, 2017-02-27 at 16:33 -0500, Brad King wrote:
> On 02/27/2017 03:50 PM, Jörg Krause wrote:
> > The problem is...
> 
> Thanks.  I've opened an issue for this here:
> 
>  https://gitlab.kitware.com/cmake/cmake/issues/16682

Great!

> > > These are set on by default in `Modules/Platform/UnixPaths.cmake`
> > > but
> > > disabled on Debian by `Modules/Platform/Linux.cmake` except when
> > > cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
> > > such that a custom `Platform/MySystem.cmake` file is loaded then
> > > the latter can set them as needed for the target platform.
> > 
> > Thanks for the hint. We are discussing this setting as a
> > workaround.
> 
> It sounds like this target platform does not want the lib32/lib64
> suffixes to be searched so this would be an appropriate setting
> for the projects to use regardless of what is done about this in
> upstream CMake.  That will also fix it for using CMake 3.7.

Buildroot does not have any problems with searching for libraries in
lib32. It does have a problem with having a host rpath used for linking
with libraries.

So, turning of the search for lib32 is really just a workaround to get
rid of the host rpath.

From my understanding, there are some possibilities to fix this issue:
1) Prefer to search in lib if FIND_LIBRARY_USE_LIB32_PATHS is enabled,
and only search in lib32 in case the target is not found in lib.
2) Make sure, in case lib32 is a symlink, to follow the symlink.
3) Make sure, in case lib32 is a symlink to lib and is not included in
the linker search paths, to add it to the implicit runtime search
paths.

Any thoughts?

Jörg
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Ray Donnelly]

On Mon, Feb 27, 2017 at 9:39 PM, Brad King  wrote:
> On 02/27/2017 03:54 PM, Ray Donnelly wrote:
>> This is why my PR asks the linker that the compiler will use for the
>> actual list of implicit link dirs. I'm sorry I've not had time to
>> write up a clear explanation yet.
>
> IIUC your case is the opposite of that under discussion in the rest
> of this thread.  You want to include a rpath that is not currently
> included.  Jörg wants to exclude a rpath that is currently being
> incorrectly included.  The detection you're proposing would not
> discover the lib32 entry that is causing Jörg's problem.
>

Not really, my PR is about ensuring that CMake's idea of implicit dirs
isn't mismatched with the linker's actual implicit dirs by actually
asking the linker. AFAICT, it fixes Jörg's problem too. I say that
because as stated:

> CMake passes the host rpath to the linker

CMake does this because it isn't *asking* the linker, it's making
assumptions instead (and adding some predefined values like
`/usr/lib32`). If we just ask the linker instead then everything
should work just fine (I am ignore linkers that cannot tell us here
like Apple's ld64. I'm not sure how to tackle that one yet).

> As I requested in your MR [1] it will be more appropriate to discuss
> your rpath-inclusion use case in a separate issue.
>
> Thanks,
> -Brad
>
> [1] https://gitlab.kitware.com/cmake/cmake/merge_requests/207#note_189880
>
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/27/2017 03:54 PM, Ray Donnelly wrote:
> This is why my PR asks the linker that the compiler will use for the
> actual list of implicit link dirs. I'm sorry I've not had time to
> write up a clear explanation yet.

IIUC your case is the opposite of that under discussion in the rest
of this thread.  You want to include a rpath that is not currently
included.  Jörg wants to exclude a rpath that is currently being
incorrectly included.  The detection you're proposing would not
discover the lib32 entry that is causing Jörg's problem.

As I requested in your MR [1] it will be more appropriate to discuss
your rpath-inclusion use case in a separate issue.

Thanks,
-Brad

[1] https://gitlab.kitware.com/cmake/cmake/merge_requests/207#note_189880

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/27/2017 03:50 PM, Jörg Krause wrote:
> The problem is...

Thanks.  I've opened an issue for this here:

 https://gitlab.kitware.com/cmake/cmake/issues/16682

>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except when
>> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
>> such that a custom `Platform/MySystem.cmake` file is loaded then
>> the latter can set them as needed for the target platform.
> 
> Thanks for the hint. We are discussing this setting as a workaround.

It sounds like this target platform does not want the lib32/lib64
suffixes to be searched so this would be an appropriate setting
for the projects to use regardless of what is done about this in
upstream CMake.  That will also fix it for using CMake 3.7.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Ray Donnelly]

On Mon, Feb 27, 2017 at 8:50 PM, Jörg Krause
 wrote:
> Hi Brad,
>
> On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
>> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>> > > > I have a PR that asks the linker (via the compiler) what its
>> > > > implicit
>> > > > search directories are instead.
>> > > >
>> > > > It is the right way to do it IMHO, but I need to find time to
>> > > > finish
>> > > > it unfortunately.
>> > >
>> > > Do you have a link to the PR?
>> >
>> > The PR Is closed pending me writing a test-case, but I just now
>> > updated to the my latest version and rebased on top of master:
>>
>> The MR was:
>>
>>  https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>>
>> See discussion there for why it has not yet been accepted.  Basically
>> I'd like to see a clear explanation of the use case.  The case
>> described
>> in the MR looks to me like the custom compiler should be configured
>> to
>> always pass the needed rpath flags to the linker.
>>
>> On 02/06/2017 06:16 PM, Jörg Krause wrote:
>> > I did a git bisect. The behaviour was introduced in commit
>> > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
>>
>> Thanks for the bisect.  I don't think there is anything wrong with
>> that
>> change on its own.  It merely exposed some existing behavior in a new
>> case.
>
> The problem is, that we end up with a host rpath when cross-compiling
> which breaks compilations for a number of CMake packages we build on
> Buildroot.

This is why my PR asks the linker that the compiler will use for the
actual list of implicit link dirs. I'm sorry I've not had time to
write up a clear explanation yet.

>
> Buildroot uses /sysroot/usr/lib as target library path and
> /sysroot/usr/lib32 is a symlink to that path. Nothing wrong here.
>
> The addition of FIND_LIBRARY_USE_LIB32_PATHS 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 paths
> 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.
>
> So, as the implicit runtime search paths does *not* contain
> `/sysroot/usr/lib32`, find_library() ends up with a rpath set to
> `/usr/lib32`.
>
>
>
> One example of how cross-compilation is broken is the example I already
> quoted:
>
> """
> $SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot-
> linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,-
> rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedtls.so
> """
>
> If libmbedtls is linked with libz, the linker tries to link the target
> libmbedtls with host libz, which fails:
>
> """
> $SYSROOT/usr/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@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> """
>
> Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link.
> Therefore, this behavior was not exposed before the commit.
>
> For me, it looks like there is a problem how the rpath is created when
> cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is
> a symlink to an implicit runtime search path?
>
> However, I am not very familiar with CMake and the insights I described
> where gathered by some hours of debugging the CMake code. Maybe I
> missed something?
>
>> > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
>> > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on
>> > Linux.
>>
>> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
>> disabled on Debian by `Modules/Platform/Linux.cmake` except when
>> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
>> such that a custom `Platform/MySystem.cmake` file is loaded then
>> the latter can set them as needed for the target platform.
>
> Thanks for the hint. We are discussing this setting as a workaround.
>
> Best regards,
> Jörg Krause
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to 

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Jörg Krause]

Hi Brad,

On Mon, 2017-02-27 at 11:43 -0500, Brad King wrote:
> On 02/07/2017 04:40 AM, Ray Donnelly wrote:
> > > > I have a PR that asks the linker (via the compiler) what its
> > > > implicit
> > > > search directories are instead.
> > > > 
> > > > It is the right way to do it IMHO, but I need to find time to
> > > > finish
> > > > it unfortunately.
> > > 
> > > Do you have a link to the PR?
> > 
> > The PR Is closed pending me writing a test-case, but I just now
> > updated to the my latest version and rebased on top of master:
> 
> The MR was:
> 
>  https://gitlab.kitware.com/cmake/cmake/merge_requests/207
> 
> See discussion there for why it has not yet been accepted.  Basically
> I'd like to see a clear explanation of the use case.  The case
> described
> in the MR looks to me like the custom compiler should be configured
> to
> always pass the needed rpath flags to the linker.
> 
> On 02/06/2017 06:16 PM, Jörg Krause wrote:
> > I did a git bisect. The behaviour was introduced in commit
> > 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].
> 
> Thanks for the bisect.  I don't think there is anything wrong with
> that
> change on its own.  It merely exposed some existing behavior in a new
> case.

The problem is, that we end up with a host rpath when cross-compiling
which breaks compilations for a number of CMake packages we build on
Buildroot.

Buildroot uses /sysroot/usr/lib as target library path and
/sysroot/usr/lib32 is a symlink to that path. Nothing wrong here.

The addition of FIND_LIBRARY_USE_LIB32_PATHS 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 paths
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.

So, as the implicit runtime search paths does *not* contain
`/sysroot/usr/lib32`, find_library() ends up with a rpath set to
`/usr/lib32`.



One example of how cross-compilation is broken is the example I already
quoted:

"""
$SYSROOT/usr/bin/i586-linux-gcc --sysroot=$SYSROOT/usr/i586-buildroot-
linux-musl/sysroot CheckSymbolExists.c.o -o cmTC_cb8f6 -Wl,-
rpath,/usr/lib32 -rdynamic $SYSROOT/usr/i586-buildroot-linux-
musl/sysroot/usr/lib32/libmbedtls.so
"""

If libmbedtls is linked with libz, the linker tries to link the target
libmbedtls with host libz, which fails:

"""
$SYSROOT/usr/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@GLIBC_2.0' 
/usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0' 
/usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1 
"""

Note, that Buildroot does not use a /sysroot/usr/lib64 symbolic link.
Therefore, this behavior was not exposed before the commit.

For me, it looks like there is a problem how the rpath is created when
cross-compiling. Maybe the logic should check, if /sysroot/usr/lib32 is
a symlink to an implicit runtime search path?

However, I am not very familiar with CMake and the insights I described
where gathered by some hours of debugging the CMake code. Maybe I
missed something?

> > My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
> > FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on
> > Linux.
> 
> These are set on by default in `Modules/Platform/UnixPaths.cmake` but
> disabled on Debian by `Modules/Platform/Linux.cmake` except when
> cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
> such that a custom `Platform/MySystem.cmake` file is loaded then
> the latter can set them as needed for the target platform.

Thanks for the hint. We are discussing this setting as a workaround.

Best regards,
Jörg Krause
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Brad King]

On 02/07/2017 04:40 AM, Ray Donnelly wrote:
>>> I have a PR that asks the linker (via the compiler) what its implicit
>>> search directories are instead.
>>>
>>> It is the right way to do it IMHO, but I need to find time to finish
>>> it unfortunately.
>>
>> Do you have a link to the PR?
>
> The PR Is closed pending me writing a test-case, but I just now
> updated to the my latest version and rebased on top of master:

The MR was:

 https://gitlab.kitware.com/cmake/cmake/merge_requests/207

See discussion there for why it has not yet been accepted.  Basically
I'd like to see a clear explanation of the use case.  The case described
in the MR looks to me like the custom compiler should be configured to
always pass the needed rpath flags to the linker.

On 02/06/2017 06:16 PM, Jörg Krause wrote:
> I did a git bisect. The behaviour was introduced in commit
> 896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].

Thanks for the bisect.  I don't think there is anything wrong with that
change on its own.  It merely exposed some existing behavior in a new case.

> My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
> FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.

These are set on by default in `Modules/Platform/UnixPaths.cmake` but
disabled on Debian by `Modules/Platform/Linux.cmake` except when
cross compiling.  If a toolchain file specifies CMAKE_SYSTEM_NAME
such that a custom `Platform/MySystem.cmake` file is loaded then
the latter can set them as needed for the target platform.

-Brad
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Ray Donnelly]

The PR Is closed pending me writing a test-case, but I just now
updated to the my latest version and rebased on top of master:

https://gitlab.kitware.com/mingwandroid/cmake/commit/b937ff949d8fdaab7d8b812d503f67f8cef69532


Cheers.


On Tue, Feb 7, 2017 at 8:37 AM,   wrote:
> Hi Ray,
>
> Am 2017-02-07 02:46, schrieb Ray Donnelly:
>>
>> I have a PR that asks the linker (via the compiler) what its implicit
>> search directories are instead.
>>
>> It is the right way to do it IMHO, but I need to find time to finish
>> it unfortunately.
>
>
> Do you have a link to the PR?
>
>> On Feb 6, 2017 11:16 PM, "Jörg Krause" 
>> wrote:
>>
>>> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:

 Hi,

 On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
>
> Hi,
>
> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> environment, CMake passes the host rpath to the linker:
>
> """ CMakeOutput.log
>
> /home/joerg/host/usr/bin/i586-linux-gcc
> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -Os -
> DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> /home/joerg/host/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
>
> """
>
> This leads to a linker error if mbedtls is linked with zlib, as
>>>
>>> the
>
> linker tries to link with the host zlib and does not find the
>>>
>>> host
>
> libc:
>
> """ CMakeError.txt
>
> /home/joerg/host/usr/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@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> [..]
>
> """
>
> I did not find any solution which allows me to remove the rpath
> from
> the check. Setting CMAKE_SKIP_RPATH does not change the build
> behaviour of the check_symbol_exists macro.
>
> From my understanding, the rpath flag should not be used when
>>>
>>> the
>
> sysroot flag is passed to the linker, right?
>
> For reference, I added a minimal example which uses Buildroot
>>>
>>> for
>
> cross-compilation.
>
> """ CMakeLists.txt
>
> cmake_minimum_required(VERSION 2.8.12)
>
> project(test)
>
> list(APPEND CMAKE_MODULE_PATH
>>>
>>> "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
>
>
> find_package(MbedTLS)
> if(MBEDTLS_FOUND)
> message(STATUS "Using mbedTLS")
> endif()
>
> """
>
> """ FindMbedTLS.cmake
>
> include(CheckSymbolExists)
>
> find_path(MBEDTLS_INCLUDE_DIRS
> NAMES mbedtls/ssl.h
> PATH_SUFFIXES include
> )
>
> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> find_library(MBEDX509_LIBRARY NAMES mbedx509)
> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
>
> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> MBEDTLS_V2)
> endif()
>
> """
>
> """ toolchainfile.cmake
>
> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> ${CMAKE_CURRENT_LIST_DIR})
>
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_SYSTEM_PROCESSOR i586)
>
> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CFLAGS")
> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CXXFLAGS")
>
> # Build type from the Buildroot configuration
> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> configuration")
>
> # Buildroot defaults flags.
> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS
>>>
>>> for
>
> executables")
>
> set(CMAKE_INSTALL_SO_NO_EXE 0)
>
> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> set(CMAKE_SYSROOT
>>>
>>> 

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[joerg . krause]

Hi Ray,

Am 2017-02-07 02:46, schrieb Ray Donnelly:

I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.

It is the right way to do it IMHO, but I need to find time to finish
it unfortunately.


Do you have a link to the PR?


On Feb 6, 2017 11:16 PM, "Jörg Krause" 
wrote:


On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:

Hi,

On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:

Hi,

when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
environment, CMake passes the host rpath to the linker:

""" CMakeOutput.log

/home/joerg/host/usr/bin/i586-linux-gcc
--sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-Os -
DNDEBUG CMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o -o
cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
/home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
/home/joerg/host/usr/i586-buildroot-linux-
musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so

"""

This leads to a linker error if mbedtls is linked with zlib, as

the

linker tries to link with the host zlib and does not find the

host

libc:

""" CMakeError.txt

/home/joerg/host/usr/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@GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
/usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
[..]

"""

I did not find any solution which allows me to remove the rpath
from
the check. Setting CMAKE_SKIP_RPATH does not change the build
behaviour of the check_symbol_exists macro.

From my understanding, the rpath flag should not be used when

the

sysroot flag is passed to the linker, right?

For reference, I added a minimal example which uses Buildroot

for

cross-compilation.

""" CMakeLists.txt

cmake_minimum_required(VERSION 2.8.12)

project(test)

list(APPEND CMAKE_MODULE_PATH

"${CMAKE_CURRENT_SOURCE_DIR}/cmake")


find_package(MbedTLS)
if(MBEDTLS_FOUND)
message(STATUS "Using mbedTLS")
endif()

"""

""" FindMbedTLS.cmake

include(CheckSymbolExists)

find_path(MBEDTLS_INCLUDE_DIRS
NAMES mbedtls/ssl.h
PATH_SUFFIXES include
)

find_library(MBEDTLS_LIBRARY NAMES mbedtls)
find_library(MBEDX509_LIBRARY NAMES mbedx509)
find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)

if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
MBEDTLS_V2)
endif()

"""

""" toolchainfile.cmake

string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
${CMAKE_CURRENT_LIST_DIR})

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR i586)

set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
CFLAGS")
set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
CXXFLAGS")

# Build type from the Buildroot configuration
set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
configuration")

# Buildroot defaults flags.
set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS

for

executables")

set(CMAKE_INSTALL_SO_NO_EXE 0)

set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
set(CMAKE_SYSROOT

"${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-

musl/sysroot")
set(CMAKE_FIND_ROOT_PATH

"${RELOCATED_HOST_DIR}/usr/i586-buildroot-

linux-musl/sysroot")
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
buildroot-linux-musl/sysroot")

# This toolchain file can be used both inside and outside
Buildroot.
set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
gcc")
set(CMAKE_CXX_COMPILER

"${RELOCATED_HOST_DIR}/usr/bin/i586-linux-

g++")

"""

What do I miss?


Note, that this project was build using CMake 3.7.2 on Debian.

When

using CMake 3.6.3, CMake does correctly not add rpath to the

cross-

linker and the check_symbol_exists() succeeds.


I did a git bisect. The behaviour was introduced in commit
896ad251de49f167f4ce3cbbcf9a6cce85a16681 [1].

My suggestion is to set FIND_LIBRARY_USE_LIB32_PATHS and
FIND_LIBRARY_USE_LIB64_PATHS to FALSE when cross-compiling on Linux.

[1]

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Ray Donnelly]

I have a PR that asks the linker (via the compiler) what its implicit
search directories are instead.

It is the right way to do it IMHO, but I need to find time to finish it
unfortunately.

On Feb 6, 2017 11:16 PM, "Jörg Krause"  wrote:

> On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> > Hi,
> >
> > On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> > > Hi,
> > >
> > > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > > environment, CMake passes the host rpath to the linker:
> > >
> > > """ CMakeOutput.log
> > >
> > > /home/joerg/host/usr/bin/i586-linux-gcc
> > > --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> > > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > > -Os   -
> > > DNDEBUGCMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o  -o
> > > cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> > > /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> > > /home/joerg/host/usr/i586-buildroot-linux-
> > > musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> > > buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so
> > >
> > > """
> > >
> > > This leads to a linker error if mbedtls is linked with zlib, as the
> > > linker tries to link with the host zlib and does not find the host
> > > libc:
> > >
> > > """ CMakeError.txt
> > >
> > > /home/joerg/host/usr/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@GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> > > /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> > > [..]
> > >
> > > """
> > >
> > > I did not find any solution which allows me to remove the rpath
> > > from
> > > the check. Setting CMAKE_SKIP_RPATH does not change the build
> > > behaviour of the check_symbol_exists macro.
> > >
> > > From my understanding, the rpath flag should not be used when the
> > > sysroot flag is passed to the linker, right?
> > >
> > > For reference, I added a minimal example which uses Buildroot for
> > > cross-compilation.
> > >
> > > """ CMakeLists.txt
> > >
> > > cmake_minimum_required(VERSION 2.8.12)
> > >
> > > project(test)
> > >
> > > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> > >
> > > find_package(MbedTLS)
> > > if(MBEDTLS_FOUND)
> > > message(STATUS "Using mbedTLS")
> > > endif()
> > >
> > > """
> > >
> > > """ FindMbedTLS.cmake
> > >
> > > include(CheckSymbolExists)
> > >
> > > find_path(MBEDTLS_INCLUDE_DIRS
> > > NAMES mbedtls/ssl.h
> > > PATH_SUFFIXES include
> > > )
> > >
> > > find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> > > find_library(MBEDX509_LIBRARY NAMES mbedx509)
> > > find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> > >
> > > if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> > > set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> > > set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> > > ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> > > check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> > > MBEDTLS_V2)
> > > endif()
> > >
> > > """
> > >
> > > """ toolchainfile.cmake
> > >
> > > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> > > ${CMAKE_CURRENT_LIST_DIR})
> > >
> > > set(CMAKE_SYSTEM_NAME Linux)
> > > set(CMAKE_SYSTEM_PROCESSOR i586)
> > >
> > > set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> > > set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> > > set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CFLAGS")
> > > set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > > CXXFLAGS")
> > >
> > > # Build type from the Buildroot configuration
> > > set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> > > configuration")
> > >
> > > # Buildroot defaults flags.
> > > set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> > > set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> > > set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> > > executables")
> > >
> > > set(CMAKE_INSTALL_SO_NO_EXE 0)
> > >
> > > set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> > > set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> > > musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> > > linux-musl/sysroot")
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > > set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> > > buildroot-linux-musl/sysroot")
> > >
> > > # This toolchain file can be used 

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Jörg Krause]

On Mon, 2017-02-06 at 22:22 +0100, Jörg Krause wrote:
> Hi,
> 
> On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> > Hi,
> > 
> > when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> > environment, CMake passes the host rpath to the linker:
> > 
> > """ CMakeOutput.log
> > 
> > /home/joerg/host/usr/bin/i586-linux-gcc  
> > --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> > -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > -Os   -
> > DNDEBUGCMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o  -o
> > cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic
> > /home/joerg/host/usr/i586-
> > buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> > /home/joerg/host/usr/i586-buildroot-linux-
> > musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> > buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so 
> > 
> > """
> > 
> > This leads to a linker error if mbedtls is linked with zlib, as the
> > linker tries to link with the host zlib and does not find the host
> > libc:
> > 
> > """ CMakeError.txt
> > 
> > /home/joerg/host/usr/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@GLIBC_2.0'
> > /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> > /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> > [..]
> > 
> > """
> > 
> > I did not find any solution which allows me to remove the rpath
> > from
> > the check. Setting CMAKE_SKIP_RPATH does not change the build
> > behaviour of the check_symbol_exists macro.
> > 
> > From my understanding, the rpath flag should not be used when the
> > sysroot flag is passed to the linker, right?
> > 
> > For reference, I added a minimal example which uses Buildroot for
> > cross-compilation.
> > 
> > """ CMakeLists.txt
> > 
> > cmake_minimum_required(VERSION 2.8.12)
> > 
> > project(test)
> > 
> > list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> > 
> > find_package(MbedTLS)
> > if(MBEDTLS_FOUND)
> > message(STATUS "Using mbedTLS")
> > endif()
> > 
> > """
> > 
> > """ FindMbedTLS.cmake
> > 
> > include(CheckSymbolExists)
> > 
> > find_path(MBEDTLS_INCLUDE_DIRS
> > NAMES mbedtls/ssl.h
> > PATH_SUFFIXES include
> > )
> > 
> > find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> > find_library(MBEDX509_LIBRARY NAMES mbedx509)
> > find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> > 
> > if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
> > set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
> > set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> > ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
> > check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> > MBEDTLS_V2)
> > endif()
> > 
> > """
> > 
> > """ toolchainfile.cmake
> > 
> > string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> > ${CMAKE_CURRENT_LIST_DIR})
> > 
> > set(CMAKE_SYSTEM_NAME Linux)
> > set(CMAKE_SYSTEM_PROCESSOR i586)
> > 
> > set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> > set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> > set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > CFLAGS")
> > set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> > CXXFLAGS")
> > 
> > # Build type from the Buildroot configuration
> > set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> > configuration")
> > 
> > # Buildroot defaults flags.
> > set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> > set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> > -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> > set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> > executables")
> > 
> > set(CMAKE_INSTALL_SO_NO_EXE 0)
> > 
> > set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> > set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> > musl/sysroot")
> > set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> > linux-musl/sysroot")
> > set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> > set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> > set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> > set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> > buildroot-linux-musl/sysroot")
> > 
> > # This toolchain file can be used both inside and outside
> > Buildroot.
> > set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > gcc")
> > set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> > g++")
> > 
> > """
> > 
> > What do I miss?
> 
> Note, that this project was build using CMake 3.7.2 on Debian. When
> using CMake 3.6.3, CMake does correctly not add rpath to the cross-
> linker and the check_symbol_exists() succeeds.

I did a git bisect. The behaviour was introduced in commit

Re: [CMake] RPATH cross-compile issue with CHECK_*_EXISTS

[Jörg Krause]

Hi,

On Sun, 2017-02-05 at 23:03 +0100, Jörg Krause wrote:
> Hi,
> 
> when using CHECK_{SYMBOL,FUNCTION}_EXISTS in a cross-compilation
> environment, CMake passes the host rpath to the linker:
> 
> """ CMakeOutput.log
> 
> /home/joerg/host/usr/bin/i586-linux-gcc  
> --sysroot=/home/joerg/host/usr/i586-buildroot-linux-musl/sysroot
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -Os   -DNDEBUGCMakeFiles/cmTC_cb8f6.dir/CheckSymbolExists.c.o  -o
> cmTC_cb8f6 -Wl,-rpath,/usr/lib32 -rdynamic /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedtls.so
> /home/joerg/host/usr/i586-buildroot-linux-
> musl/sysroot/usr/lib32/libmbedx509.so /home/joerg/host/usr/i586-
> buildroot-linux-musl/sysroot/usr/lib32/libmbedcrypto.so 
> 
> """
> 
> This leads to a linker error if mbedtls is linked with zlib, as the
> linker tries to link with the host zlib and does not find the host
> libc:
> 
> """ CMakeError.txt
> 
> /home/joerg/host/usr/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@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `free@GLIBC_2.0'
> /usr/lib32/libz.so.1: undefined reference to `fseeko64@GLIBC_2.1
> [..]
> 
> """
> 
> I did not find any solution which allows me to remove the rpath from
> the check. Setting CMAKE_SKIP_RPATH does not change the build
> behaviour of the check_symbol_exists macro.
> 
> From my understanding, the rpath flag should not be used when the
> sysroot flag is passed to the linker, right?
> 
> For reference, I added a minimal example which uses Buildroot for
> cross-compilation.
> 
> """ CMakeLists.txt
> 
> cmake_minimum_required(VERSION 2.8.12)
> 
> project(test)
> 
> list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/cmake")
> 
> find_package(MbedTLS)
> if(MBEDTLS_FOUND)
>   message(STATUS "Using mbedTLS")
> endif()
> 
> """
> 
> """ FindMbedTLS.cmake
> 
> include(CheckSymbolExists)
> 
> find_path(MBEDTLS_INCLUDE_DIRS
>   NAMES mbedtls/ssl.h
>   PATH_SUFFIXES include
> )
> 
> find_library(MBEDTLS_LIBRARY NAMES mbedtls)
> find_library(MBEDX509_LIBRARY NAMES mbedx509)
> find_library(MBEDCRYPTO_LIBRARY NAMES mbedcrypto)
> 
> if(MBEDTLS_LIBRARY AND MBEDX509_LIBRARY AND MBEDCRYPTO_LIBRARY)
>   set(CMAKE_REQUIRED_INCLUDES ${MBEDTLS_INCLUDE_DIRS})
>   set(CMAKE_REQUIRED_LIBRARIES ${MBEDTLS_LIBRARY}
> ${MBEDX509_LIBRARY} ${MBEDCRYPTO_LIBRARY})
>   check_symbol_exists(mbedtls_ssl_init "mbedtls/ssl.h"
> MBEDTLS_V2)
> endif()
> 
> """
> 
> """ toolchainfile.cmake
> 
> string(REPLACE "/usr/share/buildroot" "" RELOCATED_HOST_DIR
> ${CMAKE_CURRENT_LIST_DIR})
> 
> set(CMAKE_SYSTEM_NAME Linux)
> set(CMAKE_SYSTEM_PROCESSOR i586)
> 
> set(CMAKE_C_FLAGS_DEBUG "" CACHE STRING "Debug CFLAGS")
> set(CMAKE_CXX_FLAGS_DEBUG "" CACHE STRING "Debug CXXFLAGS")
> set(CMAKE_C_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release CFLAGS")
> set(CMAKE_CXX_FLAGS_RELEASE " -DNDEBUG" CACHE STRING "Release
> CXXFLAGS")
> 
> # Build type from the Buildroot configuration
> set(CMAKE_BUILD_TYPE Release CACHE STRING "Buildroot build
> configuration")
> 
> # Buildroot defaults flags.
> set(CMAKE_C_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CFLAGS")
> set(CMAKE_CXX_FLAGS "-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
> -D_FILE_OFFSET_BITS=64 -Os" CACHE STRING "Buildroot CXXFLAGS")
> set(CMAKE_EXE_LINKER_FLAGS "" CACHE STRING "Buildroot LDFLAGS for
> executables")
> 
> set(CMAKE_INSTALL_SO_NO_EXE 0)
> 
> set(CMAKE_PROGRAM_PATH "${RELOCATED_HOST_DIR}/usr/bin")
> set(CMAKE_SYSROOT "${RELOCATED_HOST_DIR}/usr/i586-buildroot-linux-
> musl/sysroot")
> set(CMAKE_FIND_ROOT_PATH "${RELOCATED_HOST_DIR}/usr/i586-buildroot-
> linux-musl/sysroot")
> set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
> set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
> set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
> set(ENV{PKG_CONFIG_SYSROOT_DIR} "${RELOCATED_HOST_DIR}/usr/i586-
> buildroot-linux-musl/sysroot")
> 
> # This toolchain file can be used both inside and outside Buildroot.
> set(CMAKE_C_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-gcc")
> set(CMAKE_CXX_COMPILER "${RELOCATED_HOST_DIR}/usr/bin/i586-linux-
> g++")
> 
> """
> 
> What do I miss?

Note, that this project was build using CMake 3.7.2 on Debian. When
using CMake 3.6.3, CMake does correctly not add rpath to the cross-
linker and the check_symbol_exists() succeeds.

Jörg
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: