(0023327)
Brad King (manager)
2010-11-17 08:21

What toolchain file are you using?

Normally CMake preserves the full path to library files on the link line. However, libraries in implicit linker search directories need to be split out to use "-l" because some toolchains substitute architecture-specific replacement implicit search paths under the hood. The /usr/i686-mingw32/lib directory is an implicit linker search path for that toolchain. The failure is not removing the "lib" prefix when converting to "-l" form.

Look in Source/cmComputeLinkInformation.cxx at the methods cmComputeLinkInformation::CheckImplicitDirItem and cmComputeLinkInformation::AddUserItem for comments describing what happens. If you build CMake from source and add "#define CM_COMPUTE_LINK_INFO_DEBUG" to this source file then you will get some verbose debugging output about parsing library names apart.

(0023356)
Sergey Belyashov (reporter)
2010-11-17 16:47

any regex [^(|lib|)([^/:]*)(\.dll.a|\.a|\.dll|\.lib)$]
static regex [^(|lib|)([^/:]*)(\.a)$]
shared regex [^(|lib|)([^/:]*)(\.dll.a|\.dll)$]
shared regex matched [] [libboost_signals-mgw45-mt-1_43] [.dll]
static regex matched [] [libboost_system-mgw45-mt-1_43] [.a]
static regex matched [] [libboost_program_options-mgw45-mt-1_43] [.a]
shared regex matched [] [libOpenAL32] [.dll.a]

link.txt:
... -llibboost_signals-mgw45-mt-1_43 -Wl,-Bstatic -llibboost_system-mgw45-mt-1_43 -llibboost_program_options-mgw45-mt-1_43 -Wl,-Bdynamic -llibOpenAL32 ...

(0023360)
Brad King (manager)
2010-11-17 17:14

What are the contents of the file to which CMAKE_TOOLCHAIN_FILE points?

(0023375)
Sergey Belyashov (reporter)
2010-11-18 07:30

see attachement

(0023376)
Brad King (manager)
2010-11-18 08:15

BTW, your root path can be just

set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT})

That variable is about re-rooting entire prefixes, not the actual search paths under each prefix. The Modules/Platform/WindowsPaths.cmake file already configures searches to look in the "/" prefix under the root. If you need "/usr" under the root to, then add

set(CMAKE_SYSTEM_PREFIX_PATH /usr)

to your toolchain file.

(0023377)
Brad King (manager)
2010-11-18 08:19

Somehow the CMAKE_STATIC_LIBRARY_PREFIX is getting set to "" instead of "lib". The main Modules/Platform/Windows.cmake file sets it to "", but then the Modules/Platform/Windows-GNU.cmake file sets it to "lib". Is the compiler recognized as GNU (it should print the compiler id at the beginning of a run on a fresh build tree)?

Due to this, CMake is constructing the regex "(|lib|)" instead of "(lib|)" to match library prefixes, and the leading empty-string option is preferred. This prevents the "lib" part from matching. I committed a fix to that:

http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fe3ac86 [^]

However, you'll need to work around the problem for CMake 2.8.3 and earlier by figuring out why CMAKE_STATIC_LIBRARY_PREFIX is not "lib". It is "lib" when I cross-compile from Linux to MinGW.

(0023378)
Sergey Belyashov (reporter)
2010-11-18 08:24

I replaces:
set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT} ${MINGW_ROOT}/usr/lib ${MINGW_ROOT}/usr/include ${MINGW_ROOT}/lib ${MINGW_ROOT}/include)
by:
set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT})
set(CMAKE_SYSTEM_PREFIX_PATH /usr)

but no effect.

(0023379)
Sergey Belyashov (reporter)
2010-11-18 08:25

-- The C compiler identification is GNU
-- The CXX compiler identification is GNU

(0023380)
Brad King (manager)
2010-11-18 08:47

> but no effect.

Yes, that is why the suggestion started with "BTW" (By The Way). It has nothing to do with this bug, but was merely a suggestion for cleanup of your code.

Anyway, commit 5fe3ac86 fixes this bug. Whether you want to investigate workarounds for releases of CMake not containing this fix is up to you. I can't reproduce this without adding the explicit line

set(CMAKE_STATIC_LIBRARY_PREFIX "")

to the project. You can probably fix it by adding

set(CMAKE_STATIC_LIBRARY_PREFIX "lib")

to your project, at least in some if() block that identifies this cross-compile case.

(0023381)
Sergey Belyashov (reporter)
2010-11-18 09:21

cross-compile case identifies only toolchain file. no more if() used in project. Adding this set to toolchain file has no effect as expected.
I will try apply commit 5fe3ac86 to my cmake-2.8.1.

(0023386)
Sergey Belyashov (reporter)
2010-11-18 10:24

I install cmake-2.8.3 with patch from commit 5fe3ac86. Problem fixed. Thanks.

Issue History
Date Modified	Username	Field	Change
2010-11-17 05:56	Sergey Belyashov	New Issue
2010-11-17 08:12	Brad King	Assigned To	=> Brad King
2010-11-17 08:12	Brad King	Status	new => assigned
2010-11-17 08:21	Brad King	Note Added: 0023327
2010-11-17 16:15	Sergey Belyashov	File Added: toolchain.cmake
2010-11-17 16:47	Sergey Belyashov	Note Added: 0023356
2010-11-17 17:14	Brad King	Note Added: 0023360
2010-11-18 07:30	Sergey Belyashov	Note Added: 0023375
2010-11-18 08:15	Brad King	Note Added: 0023376
2010-11-18 08:19	Brad King	Note Added: 0023377
2010-11-18 08:24	Sergey Belyashov	Note Added: 0023378
2010-11-18 08:25	Sergey Belyashov	Note Added: 0023379
2010-11-18 08:47	Brad King	Note Added: 0023380
2010-11-18 09:21	Sergey Belyashov	Note Added: 0023381
2010-11-18 10:24	Sergey Belyashov	Note Added: 0023386
2010-11-18 10:32	Brad King	Status	assigned => closed
2010-11-18 10:32	Brad King	Resolution	open => fixed
2010-11-18 10:32	Brad King	Target Version	=> CMake 2.8.4
2011-01-12 07:49	David Cole	Fixed in Version	=> CMake 2.8.4

Notes
(0023327) Brad King (manager) 2010-11-17 08:21	What toolchain file are you using? Normally CMake preserves the full path to library files on the link line. However, libraries in implicit linker search directories need to be split out to use "-l" because some toolchains substitute architecture-specific replacement implicit search paths under the hood. The /usr/i686-mingw32/lib directory is an implicit linker search path for that toolchain. The failure is not removing the "lib" prefix when converting to "-l" form. Look in Source/cmComputeLinkInformation.cxx at the methods cmComputeLinkInformation::CheckImplicitDirItem and cmComputeLinkInformation::AddUserItem for comments describing what happens. If you build CMake from source and add "#define CM_COMPUTE_LINK_INFO_DEBUG" to this source file then you will get some verbose debugging output about parsing library names apart.

(0023356) Sergey Belyashov (reporter) 2010-11-17 16:47	any regex [^(\|lib\|)([^/:])(\.dll.a\|\.a\|\.dll\|\.lib)$] static regex [^(\|lib\|)([^/:])(\.a)$] shared regex [^(\|lib\|)([^/:]*)(\.dll.a\|\.dll)$] shared regex matched [] [libboost_signals-mgw45-mt-1_43] [.dll] static regex matched [] [libboost_system-mgw45-mt-1_43] [.a] static regex matched [] [libboost_program_options-mgw45-mt-1_43] [.a] shared regex matched [] [libOpenAL32] [.dll.a] link.txt: ... -llibboost_signals-mgw45-mt-1_43 -Wl,-Bstatic -llibboost_system-mgw45-mt-1_43 -llibboost_program_options-mgw45-mt-1_43 -Wl,-Bdynamic -llibOpenAL32 ...

(0023360) Brad King (manager) 2010-11-17 17:14	What are the contents of the file to which CMAKE_TOOLCHAIN_FILE points?

(0023375) Sergey Belyashov (reporter) 2010-11-18 07:30	see attachement

(0023376) Brad King (manager) 2010-11-18 08:15	BTW, your root path can be just set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT}) That variable is about re-rooting entire prefixes, not the actual search paths under each prefix. The Modules/Platform/WindowsPaths.cmake file already configures searches to look in the "/" prefix under the root. If you need "/usr" under the root to, then add set(CMAKE_SYSTEM_PREFIX_PATH /usr) to your toolchain file.

(0023377) Brad King (manager) 2010-11-18 08:19	Somehow the CMAKE_STATIC_LIBRARY_PREFIX is getting set to "" instead of "lib". The main Modules/Platform/Windows.cmake file sets it to "", but then the Modules/Platform/Windows-GNU.cmake file sets it to "lib". Is the compiler recognized as GNU (it should print the compiler id at the beginning of a run on a fresh build tree)? Due to this, CMake is constructing the regex "(\|lib\|)" instead of "(lib\|)" to match library prefixes, and the leading empty-string option is preferred. This prevents the "lib" part from matching. I committed a fix to that: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5fe3ac86 [^] However, you'll need to work around the problem for CMake 2.8.3 and earlier by figuring out why CMAKE_STATIC_LIBRARY_PREFIX is not "lib". It is "lib" when I cross-compile from Linux to MinGW.

(0023378) Sergey Belyashov (reporter) 2010-11-18 08:24	I replaces: set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT} ${MINGW_ROOT}/usr/lib ${MINGW_ROOT}/usr/include ${MINGW_ROOT}/lib ${MINGW_ROOT}/include) by: set(CMAKE_FIND_ROOT_PATH ${MINGW_ROOT}) set(CMAKE_SYSTEM_PREFIX_PATH /usr) but no effect.

(0023379) Sergey Belyashov (reporter) 2010-11-18 08:25	-- The C compiler identification is GNU -- The CXX compiler identification is GNU

(0023380) Brad King (manager) 2010-11-18 08:47	> but no effect. Yes, that is why the suggestion started with "BTW" (By The Way). It has nothing to do with this bug, but was merely a suggestion for cleanup of your code. Anyway, commit 5fe3ac86 fixes this bug. Whether you want to investigate workarounds for releases of CMake not containing this fix is up to you. I can't reproduce this without adding the explicit line set(CMAKE_STATIC_LIBRARY_PREFIX "") to the project. You can probably fix it by adding set(CMAKE_STATIC_LIBRARY_PREFIX "lib") to your project, at least in some if() block that identifies this cross-compile case.

(0023381) Sergey Belyashov (reporter) 2010-11-18 09:21	cross-compile case identifies only toolchain file. no more if() used in project. Adding this set to toolchain file has no effect as expected. I will try apply commit 5fe3ac86 to my cmake-2.8.1.

(0023386) Sergey Belyashov (reporter) 2010-11-18 10:24	I install cmake-2.8.3 with patch from commit 5fe3ac86. Problem fixed. Thanks.

Relationships