[CMake] CMake implicit behaviour change between 3.2.2 and 3.3.1

[Dave Flogeras]

Hi list,

I recently upgraded from CMake-3.2.2 to 3.3.1 (well, Gentoo did).

I notice the following change.  From time to time I cross compile some
CMake projects against an Arm chroot.  I (admittedly) do not use a
toolchain file, but use the following invocation:

CC="armv6j-hardfloat-linux-gnueabi-gcc --sysroot=/path/to/my/arm/root"
CXX="[same idea...]" cmake ..

Then it does the standard pre-configuration, and I go on my merry way
with configure, make.

Part of the project in question is that it uses a call to
find_package_handle_standard_args() to find SQlite3 library and its
headers.  This has historically worked for me.  As of 3.3.1, it fails
when configuring, and when I dig in to the CMakeError.log I see the
reason:

/usr/bin/armv6j-hardfloat-linux-uclibceabi-gcc
--sysroot=/mnt/data/chroots/upie  -D_SQLITE3_TEST
CMakeFiles/cmTC_358ee.dir/src.c.o  -o cmTC_358ee -rdynamic
/usr/lib/libsqlite3.so
/usr/lib/libsqlite3.so: file not recognized: File format not recognized

Of course the library is not recognized since it is giving an absolute
path to the amd64 one.

while on CMake-3.2.2 it used a different (relative) linker invocation
which works:

/usr/bin/armv6j-hardfloat-linux-gnueabi-gcc
--sysroot=/mnt/data/chroots/pie/  -D_SQLITE3_TEST
CMakeFiles/cmTryCompileExec1680248064.dir/src.c.o  -o
cmTryCompileExec1680248064 -rdynamic -lsqlite3



Now I realize that I was probably getting away with murder before by
not using a toolchain file, and am fine if that is the only supported
way of doing such a cross-compile.  However, I did find it interesting
that this changed and thought perhaps it was an unwanted side-effect
of something else since usually any kind of behaviour changes in CMake
are documented and show up as a CMPXXXX policy warning.

Please advise,
Dave