The flag was added incorrectly by commit 9c3a6eb4 (Need -brtl when creating
shared libraries, 2003-05-16). According to "man ld" the -G option implies
"-brtl -bnortllib ...", -brtl implies "-brtllib", and -brtllib should only be
used for executables, not shared libraries. Therefore it is incorrect and
unnecessary to specify -brtl explicitly after -G.
Reported-by: Kevin Burge <kcburge@gmail.com>
The GNU compiler front-ends on AIX invoke the linker with flags of the
form "-L/path/to/gnu/runtime/lib" to tell ld where to find the language
runtime libraries. They depend on the default libpath behavior
documented in "man ld" to add the -L paths also to the runtime libpath
so the dynamic loader can find the language runtime libraries. This
differs from platforms whose linkers have distinct -rpath flags that
non-system compilers can use to tell the dynamic loader where to find
their language runtime libraries.
Since commit 96fd5909 (Implement linking with paths to library files,
2008-01-22) CMake always passes "-Wl,-blibpath:" followed by any
project-defined RPATH plus "/usr/lib:/lib" in order to explicitly set
the runtime libpath and avoid getting all the project -L paths in the
runtime libpath. The explicit libpath prevents the GNU compiler runtime
library -L paths from being placed in the libpath and then the dynamic
loader fails to find the language runtime libraries.
CMake already detects the implicit link directories for each language
since commit 07ea19ad (Implicit link info for C, CXX, and Fortran,
2009-07-23). Add the implicit link directories to the explicit runtime
libpath for GNU compilers on AIX to fix this use case.
Since commit c70beb4b (change the default borland stack size, 2003-05-05),
commit 1b572eb9 (remove -H flags, 2003-05-08), and commit 2d411398 (Stack size
in generated programs should be 10 meg, 2003-06-12) CMake adds link flags to
select a 10MB stack. At the time this was for consistency with our behavior on
MS, but that was recently removed by commit 51af1da3 (Remove "/STACK:10000000"
from default linker flags, 2012-11-23).
Change our Embarcadero link flags to select the default stack and heap settings
according to the compiler documentation. This is more reliable than leaving
the flags out completely as it has been reported that the linker does not
always use its documented defaults.
Suggested-by: Mathäus Mendel <contato@mathausmendel.com>
Previously we hard-coded a list of implicit framework directories but
did not account for CMAKE_OSX_SYSROOT or for changes to the list across
OS X versions. Instead we should automatically detect the framework
directories for the active toolchain.
The parent commit added the "-Wl,-v" option to ask "ld" to print its
implicit directories. It displays a block such as:
Framework search paths:
/...
Parse this block to extract the list of framework directories.
Detection may fail on toolchains that do not list their framework
directories, such as older OS X linkers. Always treat the paths
<sdk>/Library/Frameworks
<sdk>/System/Library/Frameworks
<sdk>/Network/Library/Frameworks # Older OS X only
/System/Library/Frameworks
as implicit. Note that /System/Library/Frameworks should always be
considered implicit so that frameworks CMake finds there will not
override the SDK copies.
We detect the implicit link directories for the toolchain by adding a
flag to get verbose output from the compiler front-end while linking the
ABI detection binary. Newer OS X toolchains based on Clang do not add
the implicit link directories with -L options to their internal
invocation of "ld". Instead they use a linker that comes with the
toolchain and is already configured with the proper directories.
Add the "-Wl,-v" option to ask "ld" to print its implicit directories.
It displays them in a block such as:
Library search paths:
/...
Parse this block to extract the implicit link directories.
While at it, remove the checks introduced by commit efaf335b (Skip
implicit link information on Xcode, 2009-07-23) and commit 5195a664
(Skip implicit link info for multiple OS X archs, 2009-09-22). Discard
the non-system link directories added by Xcode. Discard all detected
implicit libraries in the multi-architecture case but keep the
directories. The directories are still useful without the libraries
just to suppress addition of explicit -L options for them.
Modern apps that use multiple threads do NOT want 10 Megabytes of RAM
per thread being used for each thread's stack... Just leave off the
/STACK: argument, and let the compiler use a reasonable default value
for the stack size.
If existing single-threaded apps require the /STACK: argument because
they do need a very large stack size, they can add the flag in their
own CMakeLists files.
From the option documentation of VS >= 7.1:
"In earlier versions of Visual C++, the compiler used several discrete
heaps, and each had a finite limit. Currently, the compiler dynamically
grows the heaps as necessary up to a total heap size limit, and requires
a fixed-size buffer only to construct precompiled headers. Consequently,
the /Zm compiler option is rarely necessary."
http://msdn.microsoft.com/en-us/library/bdscwf1c.aspx
Suggested-by: Adam Moss <adam@broadcom.com>
Xcode 3.2.6 is known to break the SDK Library/Frameworks layout.
Detect and warn about this case to tell users to fix their system.
Reported-by: Matthew Brett <matthew.brett@gmail.com>
Since commit 43b74793 (OS X: Further improve default CMAKE_OSX_SYSROOT
selection, 2012-09-21) we choose a default CMAKE_OSX_SYSROOT only when
one is needed. However, the change forgot that we require a sysroot
when a deployment target is requested. Teach Darwin.cmake to choose a
default CMAKE_OSX_SYSROOT when CMAKE_OSX_DEPLOYMENT_TARGET is set.
Reported-by: Matthew Brett <matthew.brett@gmail.com>
Reported-by: Bradley Giesbrecht <pixilla@macports.org>
Remove ancient checks left from commit f5d95fb0 (Complete rework of
makefile generators expect trouble, 2002-11-08). Modern FreeBSD and
NetBSD platforms support shared libraries. When cross-compiling the
/usr/include/dlfcn.h may not exist on the host but the toolchain still
supports shared libraries.
In the response file also linker options could be passed,
and because <OBJECTS> is replaced by a response file, it
is necessary that no compiler option follows <OBJECTS>.
This reverts commit 5598d9b2a0.
Since commit f1670ab1 (Ninja: don't confuse ninja's rsp files with
nmake's, 2012-09-26) Ninja generator response files are placed in
CMakeFiles/ so the previously existing check already avoids expanding
them.
Since commit 1786b121 (OS X: Allow CMAKE_OSX_SYSROOT to be a logical SDK
name, 2012-09-21) we support names like "macosx" or "macosx10.7" as the
specified value of CMAKE_OSX_SYSROOT. Extend the SDK name->path
conversion to save the original value and also convert into a temporary
variable for the Xcode generator. Re-implement the deployment target
sanity check to detect the version from the transformed path.
Since commit 230ea218 (OS X: Improve default CMAKE_OSX_SYSROOT
selection, 2012-09-21) we always set CMAKE_OSX_SYSROOT if any SDK is
found in order to support Makefile generator builds with Xcode >= 4.3
without the command-line tools installed. However, in the basic
POSIX-only case of the Makefile generator with command-line tools and no
CMAKE_OSX_ARCHITECTURES we should not select any SDK by default.
Xcode supports SDKROOT values that just name an SDK rather than
specifying the full path to it. Recognize these values and handle them.
For Xcode we just put the value directly in the generated project file.
For Makefile generators we ask xcodebuild to provide the full path to
the named SDK.
Suggested-by: Jason DiCioccio <jd@ods.org>
Simplify the search for OSX_DEVELOPER_ROOT and allow it to fail if no
"/Developer" exists. When it does exist, always find a MacOSX SDK
inside it to use as the default CMAKE_OSX_SYSROOT. Otherwise set
CMAKE_OSX_SYSROOT to empty.
Drop the last use of CMAKE_OSX_SYSROOT_DEFAULT. Replace internal
platform variable CMAKE_${lang}_HAS_ISYSROOT with a more general
CMAKE_${lang}_SYSROOT_FLAG variable. If the -isysroot flag exists and
CMAKE_OSX_SYSROOT points to an SDK (not "/") then always add it to
compiler command lines. This is already done in the Xcode IDE.
Clang has the same interface as GNU except that we do not need to test
for the deployment target and sysroot flags. Simply set variables
CMAKE_${lang}_HAS_ISYSROOT
CMAKE_${lang}_OSX_DEPLOYMENT_TARGET_FLAG
to true because every version of Clang available on OS X supports these
flags.
This enables CMake to create Makefiles targeting Windows CE devices.
CMake needs to be run within a cross compile command prompt and requires
a toolchain file which sets CMAKE_SYSTEM_NAME to "WindowsCE" and
optionally CMAKE_SYSTEM_VERSION.
In commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23) we
accidentally flipped the 0/1 values of MSVC_IDE. Flip them back and
teach the CheckCompilerRelatedVariables test to check the variable.
Remove the old-style "Windows-cl.cmake" and its helper "cl.cmake". Load
the information through new-style "Platform/Windows-MSVC-<lang>.cmake"
files. Factor information common to C and CXX into a helper file
"Platform/Windows-MSVC.cmake" loaded from the per-language files.
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
At the top of a build tree we configure inside the CMakeFiles directory
files such as "CMakeSystem.cmake" and "CMake<lang>Compiler.cmake" to
save information detected about the system and compilers in use. The
method of detection and the exact results store varies across CMake
versions as things improve. This leads to problems when loading files
configured by a different version of CMake. Previously we ignored such
existing files only if the major.minor part of the CMake version
component changed, and depended on the CMakeCache.txt to tell us the
last version of CMake that wrote the files. This led to problems if the
user deletes the CMakeCache.txt or we add required information to the
files in a patch-level release of CMake (still a "feature point" release
by modern CMake versioning convention).
Ensure that we always have version-consistent platform information files
by storing them in a subdirectory named with the CMake version. Every
version of CMake will do its own system and compiler identification
checks even when a build tree has already been configured by another
version of CMake. Stored results will not clobber those from other
versions of CMake which may be run again on the same tree in the future.
Loaded results will match what the system and language modules expect.
Rename the undocumented variable CMAKE_PLATFORM_ROOT_BIN to
CMAKE_PLATFORM_INFO_DIR to clarify its purpose. The new variable points
at the version-specific directory while the old variable did not.
Several more recent Visual Studio Express editions are now available and
they support debug builds. Simplify our VS platform files by removing
support for these old tools. If anyone still uses them we can restore
support with a more modern way to test for them.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
Since commit c198730b (Detect Watcom compiler version with its id,
2011-12-07) the CMAKE_(C|CXX)_COMPILER_VERSION variables are set for the
Watcom compiler. Use these in Windows-wcl386.cmake to set the old
WATCOM1* version variables. This avoids using the old EXECUTE_PROCESS
command which failed due to extra quotes anyway.
Teach CMake to prefer the system default compiler automatically when no
compiler is specified. By default use "cc" for C, "CC" for C++, and
"f95" for Fortran. Load a new Platform/<os>-<lang>.cmake module to
allow each platform to specify for each language its system compiler
name(s) and/or exclude certain names.
Create Platform/(CYGWIN|Darwin|Linux|Windows)-CXX.cmake modules to
specify "c++" as the system C++ compiler name for these platforms. On
systems that use case-insensitive filesystems exclude C++ compiler names
that are distinguished from C compiler names only by case.
This will change the default compiler selection for existing build
scripts that do not specify a compiler when run on machines with
separate system and GNU compilers both installed in the PATH. We do not
make this change in default behavior lightly. However:
(1) If a given build really needs specific compilers one should specify
them explicitly e.g. by setting CC, CXX, and FC in the environment.
(2) The motivating case is to prefer the system Clang on newer OS X
systems over the older GNU compilers typically also installed. On
such systems the names "cc" and "c++" link to Clang. This is the
first platform known to CMake on which "c++" is not a GNU compiler.
The old behavior selected "gcc" for C and "c++" C++ and therefore
chooses GNU for C and Clang for C++ by default. The new behavior
selects GNU or Clang consistently for both languages on older or
newer OS X systems, respectively.
(3) Other than the motivating OS X case the conditions under which the
behavior changes do not tend to exist in default OS installations.
They typically occur only on non-GNU systems with manually-installed
GNU compilers.
(4) The consequences of the new behavior are not dire. At worst the
project fails to compile with the system compiler when it previously
worked with the non-system GNU compiler. Such failure is easy to
work around (see #1).
In short this change creates a more sensible default behavior everywhere
and fixes poor default behavior on a widely-used platform at the cost of
a modest change in behavior in less-common conditions.
4bb94c9 Ninja: sysconf() is declared in unistd.h
bb36759 Ninja: enable response file support on Mac (length 262144)
3a2c8e8 Ninja: disable work around when linking with mingw
3856e66 Ninja: error on missing rspfile_content
8c1e35c Ninja: remove some unused default arguments
7f647cf Ninja: also write link libraries to rsp file
The work around is only needed by older GCCs (only testet 4.4/4.7)
Ninja is very new so chances are high that there is also a new mingw.
Use slashes in link rsp file, because ar.exe can't handle \.
Brad King
Patrick Gansterer
Amit Kulkarni
David Cole
Peter Kümmel
Bill Hoffman
Kitware Robot