The documetnation of binutils:
https://sourceware.org/binutils/docs/binutils/ar-cmdline.html
suggests to use the parameters "q" and "c" in this order ("q" is
operation, and "c" is the modifier).
Suggested-by: Дилян Палаузов <dilyan.palauzov@aegee.org>
Starting with Xcode 7 the OSX and iOS SDKs contain only stub
files for dynamic system libraries. These stub files contain
some meta data and a list of exported sysbols in plain text.
They are handled by the toolchain like regular dylibs.
Since commit v2.8.7~31^2 (HP: Drive shared library linking with compiler
front end, 2011-12-12) the C compiler is used to link shared libraries
instead of calling the linker directly, so linker options need to be
wrapped as -Wl,-foo instead of -foo.
Since commit v2.4.0~4325 (...use gcc -shared, even for C++ libraries,
2003-03-13) we use the C compiler "gcc" to link C++ shared libraries
compiled with "g++". At the time "g++" did not know how to link shared
libraries correctly. This has long since been fixed so simply drop the
special case.
Since commit v3.1.0-rc1~564^2 (OS X: Use -iframework for system
framework directories, 2014-05-05) we test the version of Clang to see
if it supports -iframework. Fix the version test used for AppleClang
since it uses a different version scheme than upstream Clang.
Teach the Makefile and Ninja generators to substitute for an <INCLUDES>
placeholder instead of putting -I in <FLAGS>. Update our values for
CMAKE_<LANG>_COMPILE_OBJECT,
CMAKE_<LANG>_CREATE_ASSEMBLY_SOURCE, and
CMAKE_<LANG>_CREATE_PREPROCESSED_SOURCE
to place <INCLUDES> just before <FLAGS>.
Update our values for
CMAKE_<LANG>_COMPILE_OBJECT,
CMAKE_<LANG>_CREATE_ASSEMBLY_SOURCE, and
CMAKE_<LANG>_CREATE_PREPROCESSED_SOURCE
to place <DEFINES> before <FLAGS> consistently across supported
compilers. We already do this for most compilers, so update the rest
for consistency.
8f86407c Windows: Optionally generate DLL module definition files automatically
069aa93b bindexplib: Add support for "/bigobj" format objects
61bbbdcf bindexplib: Fix treatment of some symbols
de70c922 bindexplib: Teach DumpFile to return errors
8ea69dfe bindexplib: Build source as part of CMakeLib
2963cb2a bindexplib: Wrap long lines
4ff09893 bindexplib: Drop code that CMake does not need
7de8276c bindexplib: Add copyright/license notice block
65086ad7 bindexplib: Import original implementation from CERN
Create target property WINDOWS_EXPORT_ALL_SYMBOLS to automatically
generate a module definition file from MS-compatible .obj files and give
it to the linker in order to export all symbols from the .dll part of a
SHARED library.
If a Windows resource (.rc) source file is included in a STATIC library,
the VS "link" tool will process the compiled ".res" file and needs to know
the target architecture. Without it, we may get a LNK4068 warning and
possibly a LNK1112 error. Add /machine: to the default static library
flags to give the link tool the information it needs.
54676a0e Help: Add notes for topic 'ConcurrentFortran-compiler-id'
7cd539b1 Add support for Concurrent Fortran 77 Compiler
0d204c1c CMakeDetermineCompilerId: Try matching compiler output to detect id
5f0dad75 CMakeDetermineCompilerId: Refactor id build/check loop logic
c65a060e CMakeDetermineCompilerId: Optionally try some flags before no flags
At least some versions (e.g. C++ Builder 5) of the bcc32 linker are known to
write temporary files with a constant name to the current directory (e.g.
"turboc.$ln"). (This can be verified by using Process Monitor to watch the
file writes that bcc32 / ilink32 / implib make). This causes problems with
some generators that keep a constant current directory and run concurrent
linkers.
For example, the Ninja generator, by default, always has the current directory
set to the top of the build tree - resulting in conflicts between the linkers
that are simultaneously trying to write to "turboc.$ln". Symptoms include
direct errors regarding the "turboc.$ln" file, or later build steps failing due
to corrupted output from previous links that happened to link "successfully."
This is not a problem for the Borland Makefiles generator which does not
run jobs in parallel. For the Ninja generator, work around this problem
by using a link job pool of size 1.
The Concurrent Fortran compiler (ccur.com) is available on Linux and can
be used much like the GNU Fortran compiler. Currently it has no
preprocessor symbols to identify it so we need to detect it by matching
compiler output.
Suggested-by: Anthony Ette <Anthony.R.Ette@controlsdata.com>
Revert commit v3.3.0-rc1~435^2 (Windows-GNU: Do not tell find_library to
treat '.dll' as linkable, 2015-02-18). MinGW tools support linking to
'.dll' files directly and many non-CMake build systems still do not
provide a separate '.dll.a' file.
Update logic added in commit 957c2aac (RC: Simplify selection of
resource compiler based on C/C++ toolchain, 2015-05-07) to avoid
overriding CMAKE_GENERATOR_RC. The MinGW and MSYS Makefiles
generators use it to select a windres next to the compiler even
if it is not in the PATH.
Revert the refactoring by commit v2.8.11~105^2~1 (Ninja: use MinGW
generator code in EnableLanguage, 2013-03-09) and move the MinGW-
specific logic back to the "MinGW Makefiles" generator. Instead teach
the platform information modules for GNU and MSVC on Windows to set the
preferred RC compiler just before enabling the RC language. This way
we choose the RC compiler based on the C/C++ toolchain that is actually
enabled.
Green Hills MULTI is an IDE for embedded real-time systems. The IDE's
product page can be found here:
http://www.ghs.com/products/MULTI_IDE.html
It supports cross compiling on ARM, Intel x86, and other architectures
with various operating systems. The IDE exists on Linux and Windows
host systems, but CMake will currently only generate the project files
on Windows host systems.
The Xcode 5 platform specific framework locations differ from the Xcode
6 ones. Look first for the Xcode 6 ones, then for iOS Xcode 5 ones and
last for the Xcode 5 OS X ones.
For reference, the XCTest.framework is located as follows:
Xcode511.app/Contents/Developer/Library/Frameworks/XCTest.framework
Xcode511.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.1.sdk/Developer/Library/Frameworks/XCTest.framework
Xcode511.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.1.sdk/Developer/Library/Frameworks/XCTest.framework
Xcode601.app/Contents/Developer/Platforms/MacOSX.platform/Developer/Library/Frameworks/XCTest.framework
Xcode601.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/Library/Frameworks/XCTest.framework
Xcode601.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Frameworks/XCTest.framework
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
The PGI compilers on Linux do not have the -fPIE flag. Remove the table
entry added by commit v2.8.9~125^2~2 (Add platform variables for
position independent code flags, 2012-05-05), which likely included it
only as part of a sweeping introduction of such flags.
In Platform/Windows-MSVC the C and CXX flags are initialized to
contain preprocessor definitions describing the platform. On
WinCE platforms this may not be just -DWIN32. This information
may be important to RC sources too, so add such preprocessor
definitions to the default RC flags.
Suggested-by: Gunnar Roth <gunnar.roth@gmx.de>
The RC language is special in that it is automatically enabled
on Windows-based platforms when another primary language is
enabled. Move enablement of RC from early in the enablement
of the other language to late. This will allow it to use
information detected as part of enabling C, CXX, or Fortran.
3d612c73 MSVC: Compile with arch-specific flags on ARM platforms (#14552)
886dcaa7 MSVC: Distinguish among ARM architectures more precisely (#14552)
ea986676 MSVC: Define /DWINCE when building for WinCE platforms (#14552)
Otherwise find_library is unable to lookup the XCTest framework which
is not located in the SDK serach path:
In the 10.10 SDK the SDK frameworks are located here:
$DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
whereas the Platform SDKs are located here:
$DEVELOPER_DIR/Platforms/MacOSX.platform/Developer/Library/Frameworks
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
Initialize CMAKE_SHARED_LINKER_FLAGS_RELWITHDEBINFO_INIT from the value
of CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO_INIT rather than the one for
the DEBUG configuration. This typo has been present since the logic was
first added in commit 36db45082e (ENH: fix up several problems with new
stuff, 2002-11-11).
Reported-by: Gunnar Roth <gunnar.roth@gmx.de>
Revert commits:
2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
This topic was merged to master prematurely, so remove it.
Initializer lists are only properly supported in 2015 and above.
Previous Visual Studio releases said they supported initializer lists
but silently produced bad code.
Brad King
Geoff Viola
Gregor Jasny
Kars de Jong
Chuck Atkins
Stanimir Kabaivanov
Bill Hoffman
James Johnston
Zack Galbreath
Todd Gamblin
Gunnar Roth
Robert Maynard