| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On HP-UX machines some system libraries appear in architecture-specific
implicit linker search paths. We need to add these paths to our system
library search path. However, at the time we construct the search path
we do not know the target architecture.
A full solution requires re-organizing platform configuration files so
that the target architecture can be known when needed. Until that
happens we can avoid the problem by searching in both 32-bit and 64-bit
implicit link directories. By telling CMake that they are implicit
directories the generated link lines will never pass the paths, leaving
the linker free to find the library of the proper architecture even if
the find_library call finds the wrong one.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
This adds the Modules/Platform/OpenVMS.cmake platform file for OpenVMS.
We just use Unix-like rules to work with the GNV compiler front-end.
A problem with process execution currently prevents CMake link scripts
from working, so we avoid using them.
|
|
|
|
|
|
| |
HP-UX uses both .sl and .so as extensions for shared libraries. This
teaches CMake to recognize .so shared libraries so they are treated
properly during link dependency analysis.
|
|
|
|
|
|
| |
This enables the --enable-auto-import linker flag on Cygwin when linking
executables. It works with the old gcc 3.x compiler and is necessary
for the new gcc 4.x compiler. See issue #9071.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This creates variable CMAKE_<LANG>_IMPLICIT_INCLUDE_DIRECTORIES to
specify implicit include directories on a per-language basis. This
replaces the previous platform-wide variable. It is necessary to
avoid explicit specification of -I/usr/include on some compilers
(such as HP aCC) because:
1.) It may break ordering among system include directories defined
internally by the compiler, thus getting wrong system headers.
2.) It tells the compiler to treat the system include directory
as a user include directory, enabling warnings in the headers.
See issue #8598.
|
|
|
|
|
|
|
| |
We used to suppress generation of -I/usr/include (and on OSX also
-I/usr/local/include). This behavior seems to cause more trouble than
it's worth, so I'm removing it until someone encounters the original
problem it fixed. See issue #8598.
|
|
|
|
| |
10.5 was recently reinstalled on dashmacmini3 and pointed out the fact that this expression is faulty when the reported version is simply 10.5 rather than 10.5.x... for example. This fixes it.
|
|
|
|
| |
resolves the strange and difficult to diagnose (or reproduce) test failures on the dashmacmini2 Continuous dashboard.
|
|
|
|
|
|
|
| |
Some OS X linkers want a 'dylib_' prefix on the -compatiblity_version
and -current_version flags while others do not. This passes the flags
through gcc instead since it never wants the prefix and translates the
flags for the linker correctly.
|
| |
|
| |
|
|
|
|
| |
am deducing that the value of CMAKE_OSX_ARCHITECTURES_DEFAULT is responsible for the failure, although I cannot reproduce it on other builds or even by running the test via ctest interactively *on* the continuous dashboard's build...
|
|
|
|
| |
that runs on 10.3 and earlier does not understand the compiler flag it maps to...
|
|
|
|
| |
specify the target deployment runtime OS version of the built executables on Mac OSX. Thanks to Mike Jackson for the patch.
|
|
|
|
| |
followed by multiple calls to ENABLE_LANGUAGE. Use find_program to set the CMAKE_INSTALL_NAME_TOOL variable so it gets saved in the cache as a full path to the install_name_tool executable rather than a simple set which eventually goes out of scope.
|
|
|
|
|
|
| |
On 64-bit Windows there may be two Program Files folders, one for 32-bit
binaries and one for 64-bit binaries. When we compute
CMAKE_SYSTEM_PREFIX_PATH we should put both folders in the path.
|
| |
|
| |
|
| |
|
|
|
|
| |
CMAKE_BASE_NAME was used from c compiler, do the same fix for other uses of CMAKE_BASE_NAME
|
| |
|
| |
|
|
|
|
| |
flags
|
| |
|
|
|
|
|
|
|
| |
OpenBSD shared libraries use a ".so.<major>.<minor>" extension and do
not have a symlink with just a ".so" extension. Its "ld" is capable of
finding the library with the best version. This change adds support for
finding such libraries. See issue #3470.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- ld flags -dylib_compatibility_version and -dylib_current_version
are libtool flags -compatibility_version and -current_version
- OSX 10.3 does not like the dylib_ prefixes.
|
|
|
|
|
|
| |
- Map SOVERSION major.minor.patch to compatibility_version
- Map VERSION major.minor.patch to current_version
- See issue #4383.
|
| |
|
|
|
|
| |
embed the manifest files
|
| |
|
| |
|
|
|
|
| |
Fortran compiler (PGI).
|
|
|
|
| |
implicit link directories on the Sun when using the SunPro compiler.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
contributing.
|
|
|
|
| |
Fortran compilers on Linux.
|