Skip Menu |

This queue is for tickets about the Devel-Declare CPAN distribution.

Report information
The Basics
Id: 69112
Status: open
Priority: 0/
Queue: Devel-Declare
People
Owner: Nobody in particular
Requestors: MOB [...] cpan.org
Cc:
AdminCc:
Bug Information
Severity: Normal
Broken in: 0.006004
Fixed in: (no value)

History Show all quoted text
  Tue Jun 28 01:49:34 2011 MOB [...] cpan.org - Ticket created
Subject: Cygwin build error and workaround for Devel::Declare
Building Devel::Declare on cygwin usually ends with the build error: Declare.o:Declare.c:(.text+0x855): undefined reference to `_hook_op_check' collect2: ld returned 1 exit status make: *** [blib/arch/auto/Devel/Declare/Declare.dll] Error 1 during this step: g++ --shared -Wl,--enable-auto-import \ -Wl,--export-all-symbols \ -Wl,--enable-auto-image-base -L/usr/local/lib \ -fstack-protector Declare.o \ -o blib/arch/auto/Devel/Declare/Declare.dll \ /home/az/local/perl-5.14.1b/lib/5.14.1/cygwin-64int/CORE/cygperl5_14_\.dll (your directory names may vary). I was able to overcome this build error by: 1. Finding the DLL from the installation of the B::Hooks::OP::Check module, either in the install dirs or the build dirs. 2. Append the full path of this DLL to the broken g++ command above and run it. Example: g++ --shared -Wl,--enable-auto-import \ -Wl,--export-all-symbols -Wl,--enable-auto-image-base \ -L/usr/local/lib -fstack-protecor Declare.o \ -o blib/arch/auto/Devel/Declare/Declare.dll \ /home/az/local/perl-5.14.1b/lib/5.14.1/cygwin-64int/CORE/cygperl5_14_1.dll \ /home/az/local/perl-5.14.1b/lib/site_perl/5.14.1/cygwin- 64int/auto/B/Hooks/OP/Check/Check.dll 3. If that command runs successfully, continue with the build process. make make test make install I don't have a sense of what it would take to fix this issue in the Makefile.PL file. -- Marty O'Brien
  Sun Sep 11 06:24:55 2011 ZEFRAM [...] cpan.org - Correspondence added
The Makefile.PL already contains code that's meant to add the B:H:O:C DLL to the link line. It's mediated by ExtUtils::Depends. Apparently for you it's failing to do that. It would be good if you could investigate the configure-time operation of ExtUtils::Depends, to see why it's failing to come up with the right library. Or, as a blunter mode of diagnosis, try upgrading/reinstalling ExtUtils::Depends and B:H:O:C. -zefram
  Sun Sep 11 06:24:58 2011 The RT System itself - Status changed from 'new' to 'open'
  Wed Feb 01 16:26:09 2012 ZEFRAM [...] cpan.org - Correspondence added
Reini Urban has managed to reproduce the problem. He says it's a bug in ExtUtils::Depends, which shows up depending on the choice of toolchain. It should be pursued in the ExtUtils-Depends RT queue. When ExtUtils::Depends is fixed, D:D can declare the fixed version as a prereq.
  Wed Feb 01 18:57:31 2012 RURBAN [...] cpan.org - Correspondence added
I actually fixed this bug in ExtUtils::Liblist::Kid several years ago for the official cygwin distro as CYG11-5101-no-bs.patch, but it was never applied to blead. I reported it now again at https://rt.perl.org/rt3/Ticket/Display.html? id=109618 It will need a new EUMM release. I looked at Module::Install and ExtUtils::Depend again, because at first it looked like they act wrong. Why should we provide a library in fullpath as -Lpath -lname and not as a linker acceptable line /path/name.dll. ld will not find a .dll like this. The reason are various sensitive security checks in ExtUtils::Liblist::Kid to check for proper perl libs, esp. with shared libs. And this interface requires the wrongly looking API -Lpath -lname. It is odd for sure. ExtUtils::Liblist::Kid really should allow the library API as ld does, a fullpath without leading -l, and do the checks for this path. -- Reini Urban