View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0011468CMakeCMakepublic2010-11-17 05:562011-01-12 07:49
ReporterSergey Belyashov 
Assigned ToBrad King 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSLinuxOS VersionGentoo
Product VersionCMake-2-8 
Target VersionCMake 2.8.4Fixed in VersionCMake 2.8.4 
Summary0011468: Extra "lib" in -l linker flag: -llibssleay32
DescriptionI use crosscompiling for building win32 applications on Linux box.
I install required libraries (openssl) to /usr/i686-mingw32 (root of cross toolchain).
Then I try build my project. Cmake found openssl, CMakeCache.txt contains:
//Path to a file.
OPENSSL_INCLUDE_DIR:PATH=/usr/i686-mingw32/include
//Path to a library.
SSL_EAY:FILEPATH=/usr/i686-mingw32/lib/libssleay32.a

So it is Ok. Then I try compile project and it fails on linking stage:
/usr/libexec/gcc/i686-mingw32/ld: cannot find -llibssleay32

I check link.txt:
.../usr/i686-mingw32/usr/lib/libz.a /usr/i686-mingw32/usr/lib/libvorbisfile
.dll.a /usr/i686-mingw32/usr/lib/libvorbis.dll.a /usr/i686-mingw32/usr/lib/libogg.dll.a -Wl,-Bstatic -llibssleay32 -llibeay32...

What is it? Why "/usr/i686-mingw32/lib/libssleay32.a" changed to invalid -llibssleay32?
Steps To Reproduceinstall gentoo
crossdev -t i686-mingw32
crosscompile (manually) openssl-1.0.0a and install to /usr/i686-mingw32
try crosscompile any project uses cmake and links with openssl:
/usr/libexec/gcc/i686-mingw32/ld: cannot find -llibssleay32
TagsNo tags attached.
Attached Files? file icon toolchain.cmake [^] (608 bytes) 2010-11-17 16:15

- Relationships Relation Graph ] Dependency Graph ]

-  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.

- 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


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker