View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0012224 | CMake | Modules | public | 2011-05-25 15:47 | 2012-07-09 06:52 | ||||
Reporter | Jeff Trull | ||||||||
Assigned To | Rolf Eike Beer | ||||||||
Priority | normal | Severity | major | Reproducibility | always | ||||
Status | closed | Resolution | fixed | ||||||
Platform | Microsoft | OS | Windows | OS Version | 7 | ||||
Product Version | CMake 2.8.4 | ||||||||
Target Version | CMake 2.8.8 | Fixed in Version | CMake 2.8.8 | ||||||
Summary | 0012224: FindPerlLibs.cmake fails to find PERL_LIBRARY on Windows | ||||||||
Description | The PERL_LIBRARY (should be a path to perl512.lib) is not successfully found with the current code, although the executable and include paths are found OK. Under Linux (Ubuntu 10.10) it works fine for all three. | ||||||||
Steps To Reproduce | Put find_package(PerlLibs REQUIRED) into a CMakeLists.txt file and run cmake under Windows 7 with ActivePerl 5.12 installed. | ||||||||
Additional Information | This issue appears to have been first reported by Hugh Sorby in 2009: http://comments.gmane.org/gmane.comp.programming.tools.cmake.user/25824 [^] The problem seems to be due to: 1) '${PERL_EXECUTABLE} -V:libperl' output ends in a CRLF pair under windows, and at least part of that remains in the library filename being searched for 2) Under Windows ${PERL_ARCHLIB} looks like "C:\Perl\lib", so ${PERL_ARCHLIB}/CORE looks like "C:\Perl\lib/CORE", which I believe is confusing find_library() My solution (patch attached) is: 1) Use the OUTPUT_STRIP_TRAILING_WHITESPACE option when ${PERL_EXECUTABLE} is called 2) Remove the loop where each of the ${PERL_POSSIBLE_LIB_PATHS} is prepended to the ${PERL_POSSIBLE_LIBRARY_NAME} values. Given that PERL_POSSIBLE_LIB_PATHS is supplied as the PATHS argument to find_library, this seems unnecessary and also results in the above issue. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files | ![]() ![]() ![]() ![]() | ||||||||
Relationships | |
Relationships |
Notes | |
(0028555) Rolf Eike Beer (developer) 2012-02-11 11:53 |
Please check if the attached patch also solves your problem. |
(0028560) Jeff Trull (reporter) 2012-02-11 23:13 |
Unfortunately this does not resolve the problem. Although the changed regex resolves the embedded CRLF problem (issue #1), the second problem remains. After the execution of the loop, PERL_POSSIBLE_LIBRARY_NAME is as follows: C:\Perl\lib/CORE/perl512.lib;/usr/lib/perl5/5.12.3/MSWin32-x86-multi-thread/CORE/perl512.lib;/usr/lib/perl/5.12.3/MSWin32-x86-multi-thread/CORE/perl512.lib;/usr/lib/perl5/5.12.3/CORE/perl512.lib;/usr/lib/perl/5.12.3/CORE/perl512.lib The subsequent find_library is confused by this. If you replace the loop by a simple set(PERL_POSSIBLE_LIBRARY_NAME ... ) as in my patch, everything works fine. Also observe (as I noted in my original report) that PERL_POSSIBLE_LIB_PATHS is supplied to find_library anyway, so it's not necessary to list each combination of path+name in the NAMES parameter. |
(0028562) Rolf Eike Beer (developer) 2012-02-12 05:32 |
I think you are right about this loop, I would like to get rid of what is IMHO the root cause first: the backslashes in the paths. Please try the 0002 patch instead of the 0001 one. |
(0028565) Jeff Trull (reporter) 2012-02-12 17:34 |
The 0002 patch produces the same failure, although the backslashes are corrected. The value of PERL_POSSIBLE_LIBRARY_NAME is now C:/Perl/lib/CORE/perl512.lib;/usr/lib/perl5/5.12.3/MSWin32-x86-multi-thread/CORE/perl512.lib;/usr/lib/perl/5.12.3/MSWin32-x86-multi-thread/CORE/perl512.lib;/usr/lib/perl5/5.12.3/CORE/perl512.lib;/usr/lib/perl/5.12.3/CORE/perl512.lib I retried with only C:/Perl/lib/CORE/perl512.lib and that also failed. The only passing case I can find is when PERL_POSSIBLE_LIBRARY_NAME is simply "perl512.lib". |
(0028580) Rolf Eike Beer (developer) 2012-02-13 13:38 |
Ok, this should finally do it. I wondered why this did work at all and I found out that it only worked on platforms because there the library name reduced down to "perl" which was what the default of the module was anyway. |
(0028590) Jeff Trull (reporter) 2012-02-14 17:29 |
Unfortunately this time the patch fails... hunks 6 and 8, against the 2.8.7 version of FindPerlLibs.cmake |
(0028592) Rolf Eike Beer (developer) 2012-02-14 17:43 |
I have merged a more complete fix to next: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=10dfec3bb63a8f6552c1d343b6cad245e6b1abdf [^] This should fix your issue. |
(0028624) Rolf Eike Beer (developer) 2012-02-18 10:16 |
Jeff, could you please give the current version a shot? |
(0028627) Jeff Trull (reporter) 2012-02-18 14:06 |
Thanks for the update. The new version works on Windows, but fails on my Linux box (Ubuntu 11.0) with the message "Could NOT find PerlLibs (missing: PERL_LIBRARY)". Restoring the original 2.8.7 FindPerlLibs.cmake makes the message go away, so I feel confident it's not an issue with my system. |
(0028628) Rolf Eike Beer (developer) 2012-02-18 14:17 |
Please put in a shell "perl -V:libperl". I bet it write something like "libperl.so.5.12.4", i.e. it does not end in ".so". That was a bug in find_library() I found because exactly this happened on my Gentoo machine. This is alreday fixed in next, but you need to patch the CMake C++ code to get this right. If you want to be absolutely sure you could grab the CMake code and compile it yourself. Or you trust me that this will work if your libperl looks like described above. |
(0028629) Jeff Trull (reporter) 2012-02-18 14:41 |
perl -V:libperl gives the following output: libperl='libperl.so.5.12.4'; Thanks for the explanation of the issue. However, it concerns me that the FindPerlLibs.cmake from 2.8.7 works OK despite the find_library() issue, while the new FindPerlLibs.cmake does not. |
(0028630) Rolf Eike Beer (developer) 2012-02-18 15:05 |
The old module will automatically fall back to PREFIXperlSUFFIX, i.e. libperl.so. The new module will take exactly what perl has told us and only use the standard thing when "perl -V:libperl" doesn't output anything. So the old module was in fact completely ignoring what perl told you how the module was named and it then fall back to the standard name and luckily found such one. |
(0028631) Jeff Trull (reporter) 2012-02-18 18:48 |
I have built cmake from source (2.8.7.20120218-gbfbb5) and used this new FindPerlLibs.cmake, with identical results: a failure to find the library. I investigated and I find that find_library is called with the following parameters: NAMES libperl.so.5.12.4 PATHS /usr/lib/perl/5.12/CORE /usr/lib/perl5/5.12.4/x86_64-linux-gnu-thread-multi/CORE /usr/lib/perl/5.12.4/x86_64-linux-gnu-thread-multi/CORE /usr/lib/perl5/5.12.4/CORE /usr/lib/perl/5.12.4/CORE Unfortunately libperl.so.5.12.4 is located in /usr/lib, which is not one of the listed paths. |
(0028632) Rolf Eike Beer (developer) 2012-02-19 05:08 |
/usr/lib is a standard path that CMake always looks into (on Unix platforms). I can't find the revision gbfbb5 in master or next branch. Please make sure you build next, these changes are not yet merged into master. |
(0028637) Jeff Trull (reporter) 2012-02-19 17:30 |
Thanks, that was it - I was using "master". Switching to "next" succeeds (2.8.7.20120219-gd95734). |
(0028640) Rolf Eike Beer (developer) 2012-02-20 03:13 |
Thanks for the verification. |
(0029978) David Cole (manager) 2012-07-09 06:52 |
Closing resolved issues that have not been updated in more than 4 months. |
Notes |
Issue History | |||
Date Modified | Username | Field | Change |
2011-05-25 15:47 | Jeff Trull | New Issue | |
2011-05-25 15:47 | Jeff Trull | File Added: FindPerlLibs_win.patch | |
2012-02-11 11:52 | Rolf Eike Beer | File Added: 0001-FindPerlLibs-properly-cut-values-from-perl-output-12.patch | |
2012-02-11 11:53 | Rolf Eike Beer | Note Added: 0028555 | |
2012-02-11 23:13 | Jeff Trull | Note Added: 0028560 | |
2012-02-12 05:32 | Rolf Eike Beer | Note Added: 0028562 | |
2012-02-12 05:32 | Rolf Eike Beer | Assigned To | => Rolf Eike Beer |
2012-02-12 05:32 | Rolf Eike Beer | Status | new => assigned |
2012-02-12 05:33 | Rolf Eike Beer | File Added: 0002-FindPerlLibs-properly-cut-values-from-perl-output-12.patch | |
2012-02-12 17:34 | Jeff Trull | Note Added: 0028565 | |
2012-02-13 13:32 | Rolf Eike Beer | File Added: 0003-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch | |
2012-02-13 13:38 | Rolf Eike Beer | Note Added: 0028580 | |
2012-02-13 13:38 | Rolf Eike Beer | File Deleted: 0003-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch | |
2012-02-13 13:39 | Rolf Eike Beer | File Added: 0004-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch | |
2012-02-14 17:29 | Jeff Trull | Note Added: 0028590 | |
2012-02-14 17:43 | Rolf Eike Beer | Note Added: 0028592 | |
2012-02-14 17:43 | Rolf Eike Beer | Target Version | => CMake 2.8.8 |
2012-02-18 10:16 | Rolf Eike Beer | Note Added: 0028624 | |
2012-02-18 14:06 | Jeff Trull | Note Added: 0028627 | |
2012-02-18 14:17 | Rolf Eike Beer | Note Added: 0028628 | |
2012-02-18 14:41 | Jeff Trull | Note Added: 0028629 | |
2012-02-18 15:05 | Rolf Eike Beer | Note Added: 0028630 | |
2012-02-18 18:48 | Jeff Trull | Note Added: 0028631 | |
2012-02-19 05:08 | Rolf Eike Beer | Note Added: 0028632 | |
2012-02-19 17:30 | Jeff Trull | Note Added: 0028637 | |
2012-02-20 03:13 | Rolf Eike Beer | Note Added: 0028640 | |
2012-02-20 03:13 | Rolf Eike Beer | Status | assigned => resolved |
2012-02-20 03:13 | Rolf Eike Beer | Resolution | open => fixed |
2012-02-20 03:13 | Rolf Eike Beer | Fixed in Version | => CMake 2.8.8 |
2012-07-09 06:52 | David Cole | Note Added: 0029978 | |
2012-07-09 06:52 | David Cole | Status | resolved => closed |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |