[CMake] CMake 2.8.6 --> 2.8.8 New TryCompile Fails on GCC-GNAT Ada Linking

Bill Hoffman bill.hoffman at kitware.com
Mon Jul 2 10:48:31 EDT 2012


On 7/2/2012 10:22 AM, Matthew Schuchard wrote:
> So I am back for more CMake fun in attempting to get it working with our
> massive and convoluted product.  I am now trying to use my office
> computer to configure and build our software, and am hitting an issue
> with the new TryCompile in CMake 2.8.8 (or possibly 2.8.7 if it was
> introduced then).
>
> My machine is running RedHat 6 which has GNU44 as baseline (as opposed
> to earlier RHEL-5 which had GNU41 as baseline).  Fortran, C, and C++ are
> all working fine thus far with code changes I made, but I am hitting a
> snag with Ada and CMake 2.8.8.  We have a custom RPM made for CMake
> 2.8.6 RHEL-5 which interacted well with GNAT41, but I yum installed
> CMake 2.8.8 and GCC-GNAT 4.4.6 and expected everything to still perform
> the same (I am naive sometimes).
>
> I am pretty sure this issue is because of a code change made to the
> TryCompile behavior between CMake 2.8.6 and CMake 2.8.8.  TryCompile now
> creates unique directory names, i.e.
> ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/CMakeFiles/cmTryCompileExec(RANDOMNUMBERSTRING).dir/(TRYCOMPILE
> OUTPUT FILES)
> I used the --debug-trycompile argument during configuration to get some
> more information, and I see that the target name is being generated with
> the random number string.  This breaks both my custom Ada CMake
> toolchain and the freely available one on the internet because both have
> similar link statement methodologies (mine below):
>
> "${CMAKE_Ada_BUILDER} <LINK_FLAGS> <TARGET_BASE>.adb -cargs <FLAGS>
> -bargs ${CMAKE_Ada_BIND_FLAGS} -largs <CMAKE_Ada_LINK_FLAGS>
> <LINK_LIBRARIES>"
>
> This, of course, generates a link statement for TryCompile similar to
> the following:
>
> /usr/bin/gnatmake   cmTryCompileExec162931069.adb -cargs
> -gnatec/path/to/gnat.adc   -g -Wall   -bargs  -largs  -rdynamic
>
> which obviously fails since the file is named cmTryCompileExec.adb. This
> file is specified in my CMakeTestAdaCompiler.cmake via:
>
> FILE(WRITE
> ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeTmp/cmTryCompileExec.adb
>      "with Ada.Text_IO;\n"
>      "use Ada.Text_IO;\n"
>      "procedure cmTryCompileExec is\n"
>      "begin\n"
>      "Put(\"Hello World\");\n"
>      "end cmTryCompileExec;\n")
>
> <OBJECTS> does not work because it appends a ".o" extension to the
> target.  There is no way of getting around this either because
> "SET(CMAKE_Ada_OUTPUT_EXTENSION .o)" and
> "SET(CMAKE_Ada_OUTPUT_EXTENSION_REPLACE 1)" are both needed in the
> compiler configuration input file. <TARGET> fails for the same reason as
> <TARGET_BASE>.
>
> I could always try to force the Ada ABI and then it skips the
> compilation test (correct?), but i want to avoid that if at all possible.
>
> So I basically need a way to block or strip off the random number string
> from the target, or revert CMake's TryCompile behavior to the method
> from 2.8.6.  Eventually we will be updating the CMake and Redhat
> versions we officially use, so I need to get Ada working with newer
> versions of GNAT and CMake.  If there is a clean way of fixing this that
> does not involve hacking off the number string, so much the better.
>
> I am out of ideas at this point and would welcome virtually any
> suggestions.  The only feasible idea I can think of is to loop through
> the TryCompile directories and "sed" off the random number string from
> the link.txt files for Ada, which sounds really ugly, but still would
> probably work.  Thank you for your attention.
> --

Can you send a complete example?  Seems like you might be using the 
wrong signature to try_compile, but I want to see to make sure.

-Bill



More information about the CMake mailing list