On 5/2/2017 6:52 PM, Brad King wrote:
> On 05/02/2017 11:48 AM, Christian Pfeiffer wrote:
>> turn depends on libgcc_s. Any library starting with 'gcc' is being
>> ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being
>> stripped from the commandline. PGI Fortran however does not
Hello,
In issue #16752 [1] a hanging xcodebuild during try_compile is reported.
Currently I cannot manage to find the spare time it takes to handle all
CMake issues in a timely manner.
Is anyone willing to help debugging this issue and/or filing a rdar://
report? Maybe someone also knows someone
On 05/02/2017 11:48 AM, Christian Pfeiffer wrote:
> turn depends on libgcc_s. Any library starting with 'gcc' is being
> ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being
> stripped from the commandline. PGI Fortran however does not need
> libgcc_s on its own and therefore
Hi folks,
I've tried to link some code built with GNU G++ together with the PGI
Fortran compiler as linker. However, G++ pulls in libstdc++, which in
turn depends on libgcc_s. Any library starting with 'gcc' is being
ignored in CMakeParseImplicitLinkInfo.cmake L.136, so libgcc_s is being
We are pleased to announce that CMake 3.8.1 is now available for download.
Please use the latest release from our download page:
https://cmake.org/download/
Thanks for your support!
-
Changes in 3.8.1 since 3.8.0:
Alex
Am 2017-04-29 22:47, schrieb Alan W. Irwin:
My use case (which I am pretty sure is a common one) is that for
PLplot I want the default behaviour of our build system to be that it
looks for Python 3, but if that does not exist it looks for Python 2.
It appears the following logic implements that
