MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0012224CMakeModulespublic2011-05-25 15:472012-07-09 06:52
ReporterJeff Trull 
Assigned ToRolf Eike Beer 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS Version7
Product VersionCMake 2.8.4 
Target VersionCMake 2.8.8Fixed in VersionCMake 2.8.8 
Summary0012224: FindPerlLibs.cmake fails to find PERL_LIBRARY on Windows
DescriptionThe 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 ReproducePut find_package(PerlLibs REQUIRED) into a CMakeLists.txt file and run cmake under Windows 7 with ActivePerl 5.12 installed.
Additional InformationThis 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.
TagsNo tags attached.
Relationships
Attached Filespatch FindPerlLibs_win.patch (998) 2011-05-25 15:47
https://public.kitware.com/Bug/file/3897/FindPerlLibs_win.patch
patch 0001-FindPerlLibs-properly-cut-values-from-perl-output-12.patch (1,130) 2012-02-11 11:52
https://public.kitware.com/Bug/file/4212/0001-FindPerlLibs-properly-cut-values-from-perl-output-12.patch
patch 0002-FindPerlLibs-properly-cut-values-from-perl-output-12.patch (3,342) 2012-02-12 05:33
https://public.kitware.com/Bug/file/4214/0002-FindPerlLibs-properly-cut-values-from-perl-output-12.patch
patch 0004-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch (5,048) 2012-02-13 13:39
https://public.kitware.com/Bug/file/4220/0004-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch
Issue History
Date ModifiedUsernameFieldChange
2011-05-25 15:47Jeff TrullNew Issue
2011-05-25 15:47Jeff TrullFile Added: FindPerlLibs_win.patch
2012-02-11 11:52Rolf Eike BeerFile Added: 0001-FindPerlLibs-properly-cut-values-from-perl-output-12.patch
2012-02-11 11:53Rolf Eike BeerNote Added: 0028555
2012-02-11 23:13Jeff TrullNote Added: 0028560
2012-02-12 05:32Rolf Eike BeerNote Added: 0028562
2012-02-12 05:32Rolf Eike BeerAssigned To => Rolf Eike Beer
2012-02-12 05:32Rolf Eike BeerStatusnew => assigned
2012-02-12 05:33Rolf Eike BeerFile Added: 0002-FindPerlLibs-properly-cut-values-from-perl-output-12.patch
2012-02-12 17:34Jeff TrullNote Added: 0028565
2012-02-13 13:32Rolf Eike BeerFile Added: 0003-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch
2012-02-13 13:38Rolf Eike BeerNote Added: 0028580
2012-02-13 13:38Rolf Eike BeerFile Deleted: 0003-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch
2012-02-13 13:39Rolf Eike BeerFile Added: 0004-FindPerlLibs-properly-detect-libperl-on-Windows-1222.patch
2012-02-14 17:29Jeff TrullNote Added: 0028590
2012-02-14 17:43Rolf Eike BeerNote Added: 0028592
2012-02-14 17:43Rolf Eike BeerTarget Version => CMake 2.8.8
2012-02-18 10:16Rolf Eike BeerNote Added: 0028624
2012-02-18 14:06Jeff TrullNote Added: 0028627
2012-02-18 14:17Rolf Eike BeerNote Added: 0028628
2012-02-18 14:41Jeff TrullNote Added: 0028629
2012-02-18 15:05Rolf Eike BeerNote Added: 0028630
2012-02-18 18:48Jeff TrullNote Added: 0028631
2012-02-19 05:08Rolf Eike BeerNote Added: 0028632
2012-02-19 17:30Jeff TrullNote Added: 0028637
2012-02-20 03:13Rolf Eike BeerNote Added: 0028640
2012-02-20 03:13Rolf Eike BeerStatusassigned => resolved
2012-02-20 03:13Rolf Eike BeerResolutionopen => fixed
2012-02-20 03:13Rolf Eike BeerFixed in Version => CMake 2.8.8
2012-07-09 06:52David ColeNote Added: 0029978
2012-07-09 06:52David ColeStatusresolved => closed

Notes
(0028555)
Rolf Eike Beer   
2012-02-11 11:53   
Please check if the attached patch also solves your problem.
(0028560)
Jeff Trull   
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   
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   
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   
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   
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   
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   
2012-02-18 10:16   
Jeff, could you please give the current version a shot?
(0028627)
Jeff Trull   
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   
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   
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   
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   
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   
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   
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   
2012-02-20 03:13   
Thanks for the verification.
(0029978)
David Cole   
2012-07-09 06:52   
Closing resolved issues that have not been updated in more than 4 months.