[CMake] INTERPROCEDURAL_OPTIMIZATION still not using CMAKE__COMPILER_AR

[lectem]

Hello guys,

So I downloaded the 3.9 release and thought my LTO nightmares were over but… 
cmake still isn’t using 
CMAKE__COMPILER_AR when linking on MSYS.

I’m using the « MSYS Makefiles » generator, and when building an executable it 
still uses the plain ar instead of gcc-ar…

CMAKE_CXX_COMPILER_AR is correctly set to C:/msys64/mingw64/bin/gcc-ar.exe but 
won’t use it…
I also tried to set CMAKE_AR to C:/msys64/mingw64/bin/gcc-ar.exe from cmake-gui 
but it’s not taken into account
Here’s the output :

[100%] Linking CXX executable BoilerPlate.exe
"/C/Program Files/CMake/bin/cmake.exe" -E remove -f 
CMakeFiles/BoilerPlate.dir/objects.a
/C/msys64/mingw64/bin/ar.exe cr CMakeFiles/BoilerPlate.dir/objects.a 
@CMakeFiles/BoilerPlate.dir/objects1.rsp
C:\msys64\mingw64\bin\ar.exe: CMakeFiles/BoilerPlate.dir/source/main.cpp.obj: 
plugin needed to handle lto object
/C/msys64/mingw64/bin/g++.exe -flto -fno-fat-lto-objects   -Wl,--whole-archive 
CMakeFiles/BoilerPlate.dir/objects.a -Wl,--no-whole-archive  -o BoilerPlate.exe 
-Wl,--out-implib,libBoilerPlate.dll.a 
-Wl,--major-image-version,0,--minor-image-version,0 
@CMakeFiles/BoilerPlate.dir/linklibs.rsp

I’m not sure if it is a Windows/MSYS related problem (I think it is), but I 
really don’t understand why CMAKE wants to use C:/msys64/mingw64/bin/ar.exe so 
much and not the one in CMAKE_AR / CMAKE_CXX_COMPILER_AR…

If you guys have any idea.

Thanks,
Lectem
-- 

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] POSITION_INDEPENDENT_CODE's [un]expected behaviour

[Craig Scott]

Thanks for the links. I've updated the relevant issue in gitlab and also
added links to other related ones so that the full picture is captured more
or less in one place. I'll ping the dev list to see if anyone has further
updates or thoughts on the PIE picture for executables. From a very quick
look, it may be non-trivial to get all compilers/platforms updated with the
correct options and at least one issue talks about problems with QT and
having PIE being enabled, but I'll defer to the dev list to provide further
insights. You can see the updated issue with links here:

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



On Sat, Jul 22, 2017 at 3:01 AM, Oleksii Vilchanskyi via CMake <
cmake@cmake.org> wrote:

> Hello,
>
> I would like to ask about POSITION_INDEPENDENT_CODE target property. As
> of CMake 3.8.2 POSITION_INDEPENDENT_CODE appends -fPIE or -fPIC to
> CMAKE__FLAGS and CMAKE_EXE_LINKER_FLAGS when building an executable
> or a library respectively. However, to build a PIE -pie linker flag is
> additionally required. Thus POSITION_INDEPENDENT_CODE is not behaving as
> expected being a really easy to fix for someone aware with CMake codebase.
>
> Is there any reason why it wasn't added when the property was introduced?
> Somebody proposed introducing POSITION_INDEPENDENT_EXECUTABLE later on in
> addition to POSITION_INDEPENDENT_CODE to maintain backwards compatibility
> (I suppose policies are also a solution?).
>
> This email is the result of the thread
>  and the message
> 
> by Juan Navarro (big thanks to him), which fully summarizes CMake's
> POSITION_INDEPENDENT_CODE treatment and links to multiple bugs: this one
> , so far without attention, and this
> one , resolved for
> Android.
>
> Thank you.
>
> Regards,
> Oleksii Vilchanskyi
>
> --
>
> 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
>



-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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] Append to property COMPILE_DEFINITIONS

[Craig Scott]

On Tue, Jul 18, 2017 at 8:50 PM, Florian Lindner 
wrote:

> #Works, but I would prefer to have it just once for all targets and at the
> top of the file
> set_property(TARGET testprecice APPEND
>   PROPERTY COMPILE_DEFINITIONS "FOO")
>
> > BTW, you don't include the -D when adding to COMPILE_DEFINITIONS, just
> put FOO, not -DFOO. Have a read of the docs, they may give you other clues
> for this property (e.g. using the ..._CONFIG variant of it).
>
> Yeah, I found out that I don't have to add -D. The docs say that generator
> expressions are preferable to using _CONFIG
> variant.
>

So just to be crystal clear, this is what I would have expected to work if
you wanted the symbol FOO to be defined for Debug builds for all targets in
the current directory and below:

set_property(DIRECTORY APPEND PROPERTY
COMPILE_DEFINITIONS $<$:FOO>)

Note that this directory property is NOT used to initialise the
corresponding target property. Rather, BOTH are combined to give the final
set of command line compile definitions. It does not matter whether this
directory property is set before or after you call add_executable() within
the same CMakeLists.txt file (or more accurately, within the same directory
scope).



>
> >
> > On Tue, Jul 18, 2017 at 1:21 PM, Florian Lindner  > wrote:
> >
> > Am 18.07.2017 um 10:59 schrieb Craig Scott:
> > > You appear to be setting a GLOBAL property where you probably
> meant DIRECTORY. You could also consider setting the
> > > target property instead rather than applying it to all targets
> (unless that's what you want).
> >
> > I tried to set the property on all targets, therefore I thought
> GLOBAL is the right thing.
> >
> > However,
> >
> > set_property(DIRECTORY "${CMAKE_SOURCE_DIR}/src" APPEND
> >   PROPERTY COMPILE_DEFINITIONS "-DFOO")
> >
> > hasn't had any effect either.
> >
> > set_property(TARGET testprecice APPEND
> >   PROPERTY COMPILE_DEFINITIONS "FOO")
> >
> > works. But setting it on all targets is exactly what I want. How can
> I do that?
> >
> > Best,
> > Florian
> >
> > >
> > >
> > > On Tue, Jul 18, 2017 at 12:56 PM, Florian Lindner <
> mailingli...@xgm.de 
> > >> wrote:
> > >
> > > Hello,
> > >
> > > I want to add compile definitions. Since I want to use
> generator expressions, I can't use add_definitions, but
> > have to
> > > use the COMPILE_DEFINITIONS property, but neither:
> > >
> > > set_property(GLOBAL APPEND
> > >   PROPERTY COMPILE_DEFINITIONS "-DFOO")
> > >
> > > for testing
> > >
> > > or
> > >
> > > set_property(GLOBAL APPEND
> > >   PROPERTY COMPILE_DEFINITIONS $<$:-DDebug>)
> > >
> > > which should be final result, produces any -DFOO compiler
> switches.
> > >
> > > I also tried placing it before and after the add_executable
> call.
> > >
> > > What is wrong with that call?
> > >
> > > Thanks,
> > > Florian
>

-- 
Craig Scott
Melbourne, Australia
https://crascit.com
-- 

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