[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