CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2019-06-17T08:05:58-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/19362REGEX is wrong for readelf used by cpack DEB generator2019-06-17T08:05:58-04:00xkszltlREGEX is wrong for readelf used by cpack DEB generatorThe following code is used to get the soversion.
```
string(REGEX MATCH "\\(SONAME\\)[^\n]*\\[([^\n]+)\\.so\\.([^\n]*)\\]" soname "${output}")
```
However this relies on gcc's readelf.
LLVM has a slightly different version that doesn't ...The following code is used to get the soversion.
```
string(REGEX MATCH "\\(SONAME\\)[^\n]*\\[([^\n]+)\\.so\\.([^\n]*)\\]" soname "${output}")
```
However this relies on gcc's readelf.
LLVM has a slightly different version that doesn't have `()` around `SONAME`.
```
LLVM:
0x000000000000000e SONAME Library soname: [libxxxxxx.so.3]
GCC:
0x000000000000000e (SONAME) Library soname: [libxxxxxx.so.3]
```3.16.0Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/19279Error when compiling MATLAB MEX file, fails obviously on “__attribute__ ((vis...2019-11-20T11:49:02-05:00Andreas MartinError when compiling MATLAB MEX file, fails obviously on “__attribute__ ((visibility: (”default“)))”I get these errors:
gcc: error: ((visibility: No such file or directory
gcc: error: ("default"))): No such file or directory
when compiling bar.c:
```
#include <mex.h>
void mexFunction( int nlhs, mxArray* plhs[], int nrhs, co...I get these errors:
gcc: error: ((visibility: No such file or directory
gcc: error: ("default"))): No such file or directory
when compiling bar.c:
```
#include <mex.h>
void mexFunction( int nlhs, mxArray* plhs[], int nrhs, const mxArray* prhs[] )
{
}
```
with CMakeLists.txt:
```
cmake_minimum_required( VERSION 3.12 )
# Project name and version
project( foo )
set( RFC_VERSION_MAJOR "0" )
set( RFC_VERSION_MINOR "2" )
find_package( Matlab QUIET REQUIRED COMPONENTS MX_LIBRARY )
# set up matlab libraries
include_directories( ${Matlab_INCLUDE_DIRS} )
# MEX function (MATLAB)
matlab_add_mex( NAME ${PROJECT_NAME} SRC bar.c OUTPUT_NAME foobar )
```
This seems to be a problem depending on the used toolchain, since other (older) compilers work.
* System: Red Hat Enterprise Linux Workstation, release 6.10 (Santiago)
* Kernel: Linux 2.6.32-754.9.1.el6.x86_64
* Desktop: GNOME 2.28.2
* Shell: tcsh 6.17.00 (Astron)
* CMake Version 3.13.3
* Compiler: gcc-5.3.0-4
* MATLAB: R2016b
**Edit:**
Disabling lines 1072ff in FindMatlab.cmake solves the problem in this (my) case:
```
set_target_properties(${${prefix}_NAME}
PROPERTIES
DEFINE_SYMBOL "DLL_EXPORT_SYM=__attribute__ ((visibility (\"default\")))"
)
```
3.16.0Raffi EnficiaudRaffi Enficiaudhttps://gitlab.kitware.com/cmake/cmake/-/issues/19163AIX export symbols incorrect2023-05-31T13:27:33-04:00David EdelsohnAIX export symbols incorrectCMake rules for AIX do not export the correct symbols and do not use the correct mechanism to export symbols.
CMake currently invokes the AIX linker with -bexpall to export "all" symbols. This is incorrect because it does not export C+...CMake rules for AIX do not export the correct symbols and do not use the correct mechanism to export symbols.
CMake currently invokes the AIX linker with -bexpall to export "all" symbols. This is incorrect because it does not export C++ mangled symbols as defined by the Itanium ABI. (-bexpfull would export more symbols but causes even more problems and NEVER SHOULD BE USED.) Exporting too many symbols causes problems because a shared library may re-export symbols from another library causing confused dependencies, duplicate symbols and other problems. CMake should explicitly create an export list in the same manner as GNU Libtool.
CMake also creates shared libraries with -G/-brtl. This normally is not necessary and harmful. This often will overflow the TOC. It forces all global calls through function descriptors (PLTs) so that they can be overridden, but most applications are not invoked in a manner that requires symbolic overriding of symbols. The excessive use of function descriptors also greatly harms performance on AIX.
This behavior seems to have been introduced in CMake in 2013. The Mantis bug reports are unclear about the exact symptoms, but the solution needs to be redesigned in a manner more consistent with AIX semantics.3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18965LINK_DIRECTORIES: Performance Regression in in 3.132019-07-26T07:33:32-04:00RichardLINK_DIRECTORIES: Performance Regression in in 3.13By bisecting and quickfixing the autogen issue #18947 (with [autogen.patch](https://gitlab.kitware.com/cmake/cmake/uploads/a222748ec84049de38aceb1400f77ab0/autogen.patch)) I found a performance regression in the CMake run on our main re...By bisecting and quickfixing the autogen issue #18947 (with [autogen.patch](https://gitlab.kitware.com/cmake/cmake/uploads/a222748ec84049de38aceb1400f77ab0/autogen.patch)) I found a performance regression in the CMake run on our main repository (ca 3800 targets in ca 900 files) using Qt on all targets introduced with commit a71caab4 (~20% slowdown).3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18964TARGET_PROPERTY: Performance Regression in in 3.132019-07-26T07:33:33-04:00RichardTARGET_PROPERTY: Performance Regression in in 3.13By bisecting and quickfixing the autogen issue #18947 (with [autogen.patch](https://gitlab.kitware.com/cmake/cmake/uploads/a222748ec84049de38aceb1400f77ab0/autogen.patch)) I found a performance regression in the CMake run on our main re...By bisecting and quickfixing the autogen issue #18947 (with [autogen.patch](https://gitlab.kitware.com/cmake/cmake/uploads/a222748ec84049de38aceb1400f77ab0/autogen.patch)) I found a performance regression in the CMake run on our main repository (ca 3800 targets in ca 900 files) using Qt on all targets introduced with commit 2f708f5d (~8% slowdown).3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18739Android: NDK r19+ support2021-01-04T13:13:54-05:00DanilAndroid: NDK r19+ supportI've been trying to build simple Qt application with Kirigami for Android and found that ndk r19 isn't working for me and judging from the sources it couldn't work at the moment.
In r19 in `build/core/toolchains/arm-linux-androideabi-cl...I've been trying to build simple Qt application with Kirigami for Android and found that ndk r19 isn't working for me and judging from the sources it couldn't work at the moment.
In r19 in `build/core/toolchains/arm-linux-androideabi-clang/setup.mk` there no `TOOLCHAIN_ROOT` which means when clang is used
(`-DCMAKE_ANDROID_NDK_TOOLCHAIN_VERSION=clang` ) [Determine-Compiler-NDK.cmake#L120](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Android/Determine-Compiler-NDK.cmake#L120) clears `_ANDROID_TOOL_NAME` and it is expected that [Determine-Compiler-NDK.cmake#L182](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Android/Determine-Compiler-NDK.cmake#L182) will set it.
However since there is no `TOOLCHAIN_ROOT` - `_ANDROID_TOOL_NAME` is never populated and when `_ANDROID_TOOL_C_TOOLCHAIN_PREFIX` is constructed in [Determine-Compiler-NDK.cmake#L231](https://gitlab.kitware.com/cmake/cmake/blob/master/Modules/Platform/Android/Determine-Compiler-NDK.cmake#L231) it becomes incorrect.
I may be doing something inherently wrong since I'm unable to build the app with any ndk for different reasons. But this one looks like a genuine bug.
Manually adding `TOOLCHAIN_ROOT := $(call get-toolchain-root,llvm)` to setup.mk moves the build further but fails due to:
`android-ndk-r19-beta2/toolchains/llvm/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin/ld: error: cannot find -lunwind` (probably `TOOLCHAIN_ROOT` addition is just meaningless)3.16.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/1260Support for precompiled headers2019-08-29T09:38:35-04:00Kitware RobotSupport for precompiled headersThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=1260). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=1260). Further discussion may take place here.3.16.0