CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

Paul Smith
I've discovered that CMake is not correctly locating ar/strip/etc. if I
override the names of these tools on the command line.  I've tried this
with 3.5.2 as well and I get the same incorrect behavior.

Here's an example (this is on a GNU/Linux system):

$ type -a my-ar
/work/bin/my-ar

$ my-ar --version | head -n1
GNU ar (GNU Binutils) 2.30

$ pwd
/tmp/obj

$ cat ../CMakeLists.txt
PROJECT(foobar)
CMAKE_MINIMUM_REQUIRED(VERSION 3.0)

$ cmake --version | head -n1
cmake version 3.11.3

$ cmake -DCMAKE_AR=my-ar ..
  ...

$ grep CMAKE_AR CMakeCache.txt
CMAKE_AR:FILEPATH=/tmp/obj/my-ar
//ADVANCED property for variable: CMAKE_AR
CMAKE_AR-ADVANCED:INTERNAL=1


Note how, instead of either using just "my-ar" or else the fully-
qualified path "/work/bin/my-ar", CMake uses the bogus and completely
non-existent path "/tmp/obj/my-ar".  This causes my builds to fail,
obviously.

I tried enabling debug-output, trace, and trace-expand but there are no
clues there as to why CMake prefixes these paths with the local object
directory.

I should note that resetting the C and C++ compilers works:

 * -DCMAKE_C_COMPILER=my-gcc   --> CMAKE_C_COMPILER=/work/bin/my-gcc
 * -DCMAKE_CXX_COMPILER=my-g++ --> CMAKE_CXX_COMPILER=/work/bin/my-g++

But all the other bintools variable overrides do the wrong thing:

 * -DCMAKE_AR=my-ar           --> CMAKE_AR=/tmp/obj/my-ar
 * -DCMAKE_LINKER=my-ld       --> CMAKE_LINKER=/tmp/obj/my-ld
 * -DCMAKE_RANLIB=my-ranlib   --> CMAKE_RANLIB=/tmp/obj/my-ranlib
 * -DCMAKE_STRIP=my-strip     --> CMAKE_STRIP=/tmp/obj/my-strip
 * -DCMAKE_OBJCOPY=my-objcopy --> CMAKE_OBJCOPY=/tmp/obj/objcopy

Can anyone explain this, and hopefully help me find a way to fix it?
Am I just doing variables wrong here?  How should I do it?

Thanks!
--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

Deniz Bahadir-2
Am 14.06.2018 um 07:05 schrieb Paul Smith:

> I've discovered that CMake is not correctly locating ar/strip/etc. if I
> override the names of these tools on the command line.  I've tried this
> with 3.5.2 as well and I get the same incorrect behavior.
>
> Here's an example (this is on a GNU/Linux system):
>
> $ type -a my-ar
> /work/bin/my-ar
>
> $ my-ar --version | head -n1
> GNU ar (GNU Binutils) 2.30
>
> $ pwd
> /tmp/obj
>
> $ cat ../CMakeLists.txt
> PROJECT(foobar)
> CMAKE_MINIMUM_REQUIRED(VERSION 3.0)
>
> $ cmake --version | head -n1
> cmake version 3.11.3
>
> $ cmake -DCMAKE_AR=my-ar ..
>    ...
>
> $ grep CMAKE_AR CMakeCache.txt
> CMAKE_AR:FILEPATH=/tmp/obj/my-ar
> //ADVANCED property for variable: CMAKE_AR
> CMAKE_AR-ADVANCED:INTERNAL=1
>
>
> Note how, instead of either using just "my-ar" or else the fully-
> qualified path "/work/bin/my-ar", CMake uses the bogus and completely
> non-existent path "/tmp/obj/my-ar".  This causes my builds to fail,
> obviously.
>
> I tried enabling debug-output, trace, and trace-expand but there are no
> clues there as to why CMake prefixes these paths with the local object
> directory.
>
> I should note that resetting the C and C++ compilers works:
>
>   * -DCMAKE_C_COMPILER=my-gcc   --> CMAKE_C_COMPILER=/work/bin/my-gcc
>   * -DCMAKE_CXX_COMPILER=my-g++ --> CMAKE_CXX_COMPILER=/work/bin/my-g++

I would not have this expected to work.

>
> But all the other bintools variable overrides do the wrong thing:
>
>   * -DCMAKE_AR=my-ar           --> CMAKE_AR=/tmp/obj/my-ar
>   * -DCMAKE_LINKER=my-ld       --> CMAKE_LINKER=/tmp/obj/my-ld
>   * -DCMAKE_RANLIB=my-ranlib   --> CMAKE_RANLIB=/tmp/obj/my-ranlib
>   * -DCMAKE_STRIP=my-strip     --> CMAKE_STRIP=/tmp/obj/my-strip
>   * -DCMAKE_OBJCOPY=my-objcopy --> CMAKE_OBJCOPY=/tmp/obj/objcopy
>

This is what I would have expected.
If you just give the executable's name as value to the variable an
implicit "./" is seen by CMake which when translated into an absolute
path results in "./" being replaced by the current working-directory of
CMake (which seems to be "/tmp/obj/").

> Can anyone explain this, and hopefully help me find a way to fix it?
> Am I just doing variables wrong here?  How should I do it?

I recommend to us the fully qualified path to your alternative
executables as values for the variables. That should do the trick.

>
> Thanks!
>

HTH,
Deniz

PS: You are right that the behavior seems to be inconsistent for
different variables and should be similar for all variables. So I
recommend you file a bug-report in CMake's issue-tracker.

--

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:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: CMake 3.11: Gives wrong paths to ar/strip/etc. when overridden

Paul Smith
On Thu, 2018-06-14 at 11:41 +0200, Deniz Bahadir wrote:

> > But all the other bintools variable overrides do the wrong thing:
> >
> >    * -DCMAKE_AR=my-ar           --> CMAKE_AR=/tmp/obj/my-ar
> >    * -DCMAKE_LINKER=my-ld       --> CMAKE_LINKER=/tmp/obj/my-ld
> >    * -DCMAKE_RANLIB=my-ranlib   --> CMAKE_RANLIB=/tmp/obj/my-ranlib
> >    * -DCMAKE_STRIP=my-strip     --> CMAKE_STRIP=/tmp/obj/my-strip
> >    * -DCMAKE_OBJCOPY=my-objcopy --> CMAKE_OBJCOPY=/tmp/obj/objcopy
> >
>
> This is what I would have expected.
> If you just give the executable's name as value to the variable an
> implicit "./" is seen by CMake which when translated into an
> absolute path results in "./" being replaced by the current working-
> directory of CMake (which seems to be "/tmp/obj/").

Thanks for the note!

IMO, that's just manifestly wrong behavior.

Either CMake should leave my values alone and use them exactly as I set
them, or if it wants to handle these values specially because it knows
they are binaries and wants to enforce a fully-qualified path (which is
unnecessary IMO but whatever), then at least it should do that
correctly and perform a PATH lookup for them.

Forcing them to be "./binary" when that's not what I said is completely
unexplainable.  In what universe would looking for CMAKE_AR, etc. in
the local directory ever be the right thing to do?

> > Can anyone explain this, and hopefully help me find a way to fix
> > it?  Am I just doing variables wrong here?  How should I do it?
>
> I recommend to us the fully qualified path to your alternative
> executables as values for the variables. That should do the trick.

So you're saying that rather than relying on the operating system's
path lookup capabilities, which exist for exactly this reason, I have
to recreate that operation myself by hand (or in some sort of wrapper
script) for all my binaries before I can invoke cmake?

> PS: You are right that the behavior seems to be inconsistent for
> different variables and should be similar for all variables. So I
> recommend you file a bug-report in CMake's issue-tracker.

That does seem like the next step.  Filed:

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

Thanks!
--

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:
https://cmake.org/mailman/listinfo/cmake