Skip Menu |

This queue is for tickets about the ExtUtils-Depends CPAN distribution.

Report information
The Basics
Id: 45224
Status: open
Priority: 0/
Queue: ExtUtils-Depends

People
Owner: Nobody in particular
Requestors: rafl [...] debian.org
Cc: CHORNY [...] cpan.org
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.301
Fixed in: (no value)

Attachments


Subject: Fails to link against declared dependencies on strawberry perl
From reading the source code I get the impression that the dl_load_flags trick to make symbols available for linking at runtime doesn't work in win32 and that linking against the binary parts of an xs extension is necessary. However, this doesn't appear to be working on strawberry perl. Undefined symbols and a failing build process is the consequence. See the following test report for Devel::Declare, which requires symbols from B::Hooks::OP::Check to work correctly, for an example of the problem: http://www.nntp.perl.org/group/perl.cpan.testers/2009/04/msg3716457.html
RT-Send-CC: kaffeetisch [...] gmx.de
Attached is a patch against r63 of svn://svn.gnome.org/svn/perl-ExtUtils- Depends that fixes the issue for us.
From bef060c33110de5d3579248dff9a2c0f1f60dfe7 Mon Sep 17 00:00:00 2001 From: Ash Berlin <ash_github@firemirror.com> Date: Fri, 1 May 2009 12:42:48 +0100 Subject: [PATCH] Fix linking of modules on Win32 (they need a .lib there at compile time) --- Changes | 3 +++ lib/ExtUtils/Depends.pm | 37 ++++++++++++++++++++++++++++++++++--- 2 files changed, 37 insertions(+), 3 deletions(-) diff --git a/Changes b/Changes index 522ad41..5dff481 100644 --- a/Changes +++ b/Changes @@ -1,5 +1,8 @@ Revision history for Perl extension ExtUtils::Depends. + - Support linking against .dll files correctly for Strawbery perl (needed + for Devel::Declare. Patch by Ash Berlin) + 0.301 Sat Sep 6 20:11:01 CEST 2008 - On Cygwin, link directly against the DLLs of dependencies. Patch by Yaakov. diff --git a/lib/ExtUtils/Depends.pm b/lib/ExtUtils/Depends.pm index adc9d79..50b4317 100644 --- a/lib/ExtUtils/Depends.pm +++ b/lib/ExtUtils/Depends.pm @@ -7,6 +7,7 @@ package ExtUtils::Depends; use strict; use warnings; use Carp; +use Config; use File::Find; use File::Spec; use Data::Dumper; @@ -241,7 +242,7 @@ sub get_makefile_vars { # collect and uniquify things from the dependencies. # first, ensure they are completely loaded. $self->load_deps; - + ##my @defbits = map { split } @{ $self->{defines} }; my @incbits = map { split } @{ $self->{inc} }; my @libsbits = split /\s+/, $self->{libs}; @@ -282,6 +283,8 @@ sub get_makefile_vars { TYPEMAPS => [@typemaps], ); + $self->build_dll_lib(\%vars) if $^O =~ /MSWin32/; + # we don't want to provide these if there is no data in them; # that way, the caller can still get default behavior out of # MakeMaker when INC, LIBS and TYPEMAPS are all that are required. @@ -297,12 +300,20 @@ sub get_makefile_vars { %vars; } +sub build_dll_lib { + my ($self, $vars) = @_; + (my $stem = $self->{name}) =~ s/^.*:://; + my $ext = $Config{lib_ext}; + $vars->{macro} ||= {}; + $vars->{macro}{'INST_DNYAMIC_LIB'} = '$(INST_ARCHAUTODIR)/$(BASEEXT)$(LIB_EXT)'; +} + sub find_extra_libs { my $self = shift; my %mappers = ( - MSWin32 => sub { $_[0] . '.lib' }, - cygwin => sub { $_[0] . '.dll'}, + MSWin32 => sub { $_[0] . '\.(?:lib|a)' }, + cygwin => sub { $_[0] . '\.dll'}, ); my $mapper = $mappers{$^O}; return () unless defined $mapper; @@ -331,6 +342,26 @@ sub find_extra_libs { return @found_libs; } + +require ExtUtils::MY; +package # + ExtUtils::MM; + + +# This isn't actualy a static lib. it just has the same name on Win32 +sub static_lib { + + my $base = shift->SUPER::static_lib(@_); + + return $base + unless $^O =~ /MSWin32/; + + return "# This isn't actualy a static lib. it just has the same name on Win32\n" . + $(INST_DNYAMIC_LIB): $(INST_DYNAMIC)'. "\n\t" . + 'dlltool --def $(EXPORT_LIST) --output-lib $@ --dllname $(BASEEXT).$(SO) $(INST_DYNAMIC)' . + "\n\ndynamic:: \$(INST_DNYAMIC_LIB)\n"; +} + 1; __END__ -- 1.6.0.2+GitX
I confirm this fixes the problem.
I was able to install Devel::Declare and MooseX::Declare after installing patched ExtUtils::Depends and reinstalling modules that depend on it. I'm attaching dist (with this patch and from RT#46128) that is ready for testing and uploading to PAUSE. -- Alexandr Ciornii, http://chorny.net
Download ExtUtils-Depends-0.302.zip
application/zip 19.8k

Message body not shown because it is not plain text.

On Fri May 01 07:48:49 2009, ASH wrote: Show quoted text
> Attached is a patch against r63 of svn://svn.gnome.org/svn/perl-ExtUtils- > Depends that fixes the issue for us.
Is this really something that should be in ExtUtils::Depnds rather than ExtUtils::MakeMaker. It seems to me like the patch alters the internals of EU::MM -- so why not patch it directly? Also, can anyone verify that this doesn't break the build on cygwin or ActiveState with MSVC?
On Fri May 01 07:48:49 2009, ASH wrote: Show quoted text
> Attached is a patch against r63 of svn://svn.gnome.org/svn/perl-ExtUtils- > Depends that fixes the issue for us.
Shouldn't this be in ExtUtils::MakeMaker instead? It seems to me like the patch alters internals of EU::MM -- so why not patch it directly? Also, can anyone verify that this doesn't break the build on cygwin and on ActiveState perl with MSVC?
Subject: patch tested on various win32 platforms
Attached is ash's patch with a minor modification necessary for visual studio. I've tested it on: strawberry activeperl+visual studio activeperl+mingw+dmake cygwin And it works correctly in all of them. -- Rafael
--- ./lib/ExtUtils/Depends.pm 2009-05-21 08:38:53.000000000 -0700 +++ ../eud-git/./lib/ExtUtils/Depends.pm 2009-05-22 07:33:27.000000000 -0700 @@ -1,5 +1,5 @@ # -# $Id: Depends.pm 61 2008-10-05 12:49:32Z tsch $ +# $Id$ # package ExtUtils::Depends; @@ -7,6 +7,7 @@ use strict; use warnings; use Carp; +use Config; use File::Find; use File::Spec; use Data::Dumper; @@ -241,7 +242,7 @@ # collect and uniquify things from the dependencies. # first, ensure they are completely loaded. $self->load_deps; - + ##my @defbits = map { split } @{ $self->{defines} }; my @incbits = map { split } @{ $self->{inc} }; my @libsbits = split /\s+/, $self->{libs}; @@ -282,6 +283,8 @@ TYPEMAPS => [@typemaps], ); + $self->build_dll_lib(\%vars) if $^O =~ /MSWin32/; + # we don't want to provide these if there is no data in them; # that way, the caller can still get default behavior out of # MakeMaker when INC, LIBS and TYPEMAPS are all that are required. @@ -297,12 +300,20 @@ %vars; } +sub build_dll_lib { + my ($self, $vars) = @_; + (my $stem = $self->{name}) =~ s/^.*:://; + my $ext = $Config{lib_ext}; + $vars->{macro} ||= {}; + $vars->{macro}{'INST_DNYAMIC_LIB'} = '$(INST_ARCHAUTODIR)/$(BASEEXT)$(LIB_EXT)'; +} + sub find_extra_libs { my $self = shift; my %mappers = ( - MSWin32 => sub { $_[0] . '.lib' }, - cygwin => sub { $_[0] . '.dll'}, + MSWin32 => sub { $_[0] . '\.(?:lib|a)' }, + cygwin => sub { $_[0] . '\.dll'}, ); my $mapper = $mappers{$^O}; return () unless defined $mapper; @@ -331,6 +342,26 @@ return @found_libs; } + +require ExtUtils::MY; +package # + ExtUtils::MM; + + +# This isn't actualy a static lib. it just has the same name on Win32 +sub static_lib { + + my $base = shift->SUPER::static_lib(@_); + + return $base + unless $^O =~ /MSWin32/ && $Config{cc} =~ /^gcc/i; + + return "# This isn't actualy a static lib. it just has the same name on Win32\n" . + '$(INST_DNYAMIC_LIB): $(INST_DYNAMIC)'. "\n\t" . + 'dlltool --def $(EXPORT_LIST) --output-lib $@ --dllname $(BASEEXT).$(SO) $(INST_DYNAMIC)' . + "\n\ndynamic:: \$(INST_DNYAMIC_LIB)\n"; +} + 1; __END__
Subject: Re: [rt.cpan.org #45224] patch tested on various win32 platforms
Date: Sun, 24 May 2009 20:40:30 +0200
To: bug-ExtUtils-Depends [...] rt.cpan.org
From: Torsten Schoenfeld <kaffeetisch [...] gmx.de>
Rafael Kitover via RT wrote: Show quoted text
> Queue: ExtUtils-Depends > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=45224 > > > Attached is ash's patch with a minor modification necessary for visual > studio. > > I've tested it on: > > strawberry > activeperl+visual studio > activeperl+mingw+dmake > cygwin > > And it works correctly in all of them.
Thanks, that's good to know. But still: I don't see why this has to be done in EU::Depends. Why can't it be done in ExtUtils::MakeMaker? Also, there's a typo in the patch: INST_DNYAMIC_LIB should probably be INST_DYNAMIC_LIB.
On Sun May 24 14:40:50 2009, TSCH wrote: Show quoted text
> But still: I don't see why this has to be done in EU::Depends. Why > can't it be done in ExtUtils::MakeMaker?
There's no reason it *can't* be done in EUMM. However, the functionality provided by this patch is irrelevant for EUMM. It's only necessary if you want to link XS extensions against XS extensions, which, to my understanding, is what EU::Depends is trying to achieve.
RT-Send-CC: elspicyjack [...] gmail.com, ari.jolma [...] tkk.fi, raherh [...] gmail.com
On Wed May 27 19:43:09 2009, FLORA wrote: Show quoted text
> > But still: I don't see why this has to be done in EU::Depends. Why > > can't it be done in ExtUtils::MakeMaker?
> > There's no reason it *can't* be done in EUMM. However, the functionality > provided by this patch is irrelevant for EUMM. It's only necessary if > you want to link XS extensions against XS extensions, which, to my > understanding, is what EU::Depends is trying to achieve.
Well, it's still EU::MakeMaker's job to properly build shared libraries. If that involves creating an import library, then EU::MM should do that. And in fact, there's some code in EU::MM_Win32 that refers to dlltool: <http://github.com/schwern/extutils-makemaker/blob/2f447deef9246daa0e0e0cd70fbbdf860826977a/lib/ExtUtils/MM_Win32.pm#L312>. But I don't want to be complicated about this. If this patch solves your problems and doesn't break other things, then let's get it in. I'd like to hear a few second opinions first, though. spicy jack, Ari, rahed: I remember you having similar problems with linking on win32, and also that you had to manually invoke dlltool to fix it. Do you think the patch in this ticket is a correct fix to this problem? https://rt.cpan.org/Ticket/Attachment/608989/308780/eud-final.patch Specifically, spicy jack, I see that your most recent patch set at <http://code.google.com/p/camelbox/source/browse/trunk/build-extras/#build-extras/2009.1-tahi> doesn't anymore include patches that invoke dlltool. Is this not necessary for you anymore? On a more general note: would any of you who are using ExtUtils::Depends on win32/mingw/cygwin be willing to take over maintainership of the win32/mingw/cygwin parts of it?
Subject: Re: [rt.cpan.org #45224] Fails to link against declared dependencies on strawberry perl
Date: Sat, 6 Jun 2009 11:34:18 -0700
To: bug-ExtUtils-Depends [...] rt.cpan.org
From: Brian Manning <elspicyjack [...] gmail.com>
On Sat, Jun 6, 2009 at 10:35 AM, Torsten Schoenfeld via RT<bug-ExtUtils-Depends@rt.cpan.org> wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=45224 > > Specifically, spicy jack, I see that your most recent patch set at > <http://code.google.com/p/camelbox/source/browse/trunk/build-extras/#build-extras/2009.1-tahi> > doesn't anymore include patches that invoke dlltool.  Is this not > necessary for you anymore?
I had my heart set on trying to find the magick invocation of MinGW's GCC so that import libraries aren't needed, as you said that you don't use them with Gtk2-Perl on MSVC. Until I have it figured it out, I've been running dlltool by hand in order to create the needed import libraries to build the Gtk2-Perl stack with MinGW on $^O = MSWin32. A swift glance at the patch tells me that it runs the same dlltool command that I've been issuing by hand. I won't be able to actually patch and test for a few days however. Thanks, Brian
CC: elspicyjack [...] gmail.com, raherh [...] gmail.com
Subject: Re: [rt.cpan.org #45224] Fails to link against declared dependencies on strawberry perl
Date: Mon, 08 Jun 2009 23:29:55 +0300
To: bug-ExtUtils-Depends [...] rt.cpan.org
From: Ari Jolma <ari.jolma [...] tkk.fi>
Torsten Schoenfeld via RT kirjoitti: Show quoted text
> But I don't want to be complicated about this. If this patch solves > your problems and doesn't break other things, then let's get it in. > > I'd like to hear a few second opinions first, though. > > spicy jack, Ari, rahed: I remember you having similar problems with > linking on win32, and also that you had to manually invoke dlltool to > fix it. Do you think the patch in this ticket is a correct fix to this > problem? > > https://rt.cpan.org/Ticket/Attachment/608989/308780/eud-final.patch >
I tested this with Glib, Cairo, Pango, and Gtk2 and with the first three it seems to work ok. With Gtk2 I have problems that are related to Pango. First, all needed functions are not exported (gtk2perl_* - I can fix that by adding them to pango.exports). Second, linking Gtk2.dll has problems reading(??) Pango.a (it complains of an undefined reference to SvPangoRectangle and similar functions), linking works if I give Pango.dll to g++, but then Gtk2.dll refers to dll.exp.dll having Pango functions and it won't load. I suspect these are more Pango and Gtk2 build problems than EU::Depends problems. I don't have enought time to investigate this more and wanted to report this. (I also reported a problem and a fix with 64bit integers on Perl-Gtk2 list). (I switched back to non-hacked ExtUtils::MakeMaker and I now have again the problem with GTK import libs being called *.dll.a, but I went around this with hacking the pkgconfig files) Ari -- Prof. Ari Jolma Environmental Management Information Technology Teknillinen Korkeakoulu / Helsinki University of Technology tel: +358 9 4511 address: POBox 5300, 02015 TKK, Finland Email: ari.jolma at tkk.fi URL: http://geoinformatics.tkk.fi
On Ma 08.kesä 2009 13:30:22, ari.jolma@tkk.fi wrote: Show quoted text
> I tested this with Glib, Cairo, Pango, and Gtk2. > With Gtk2 I have problems.
The problem was that SvPangoRectangle and newSVPangoRectangle were listed in Gtk2.exports. (Is that a Gtk2 bug or is it because of my config?) After removing them Gtk2 compiles and links fine. The only remaining problem I have is the extension of the import libraries. I seems that in msys they usually(?) get named as .dll.a. For example the GTK+ import files are .dll.a. This is not understood by EU::MM, but I'm not sure where it should be fixed. My conclusion is that this patch is useful. Ari
From: toapole [...] gmail.com
Птн. Май 15 17:38:35 2009, CHORNY писал: Show quoted text
> I was able to install Devel::Declare and MooseX::Declare after > installing patched ExtUtils::Depends and reinstalling modules that > depend on it. > > I'm attaching dist (with this patch and from RT#46128) that is ready for > testing and uploading to PAUSE. >
What modules did you reinstall after installing patched ExtUtils::Depends?
On Tue Jun 09 14:24:15 2009, AJOLMA wrote: Show quoted text
> On Ma 08.kesä 2009 13:30:22, ari.jolma@tkk.fi wrote:
> > I tested this with Glib, Cairo, Pango, and Gtk2. > > With Gtk2 I have problems.
> > The problem was that SvPangoRectangle and newSVPangoRectangle were > listed in Gtk2.exports. (Is that a Gtk2 bug or is it because of my > config?) After removing them Gtk2 compiles and links fine.
This was an oversight that has already been fixed in the repository. Show quoted text
> My conclusion is that this patch is useful.
OK then. I committed a slightly modified version of the patch: <http://git.gnome.org/cgit/perl-ExtUtils-Depends/commit/?id=6c4341d19f>. I'll release a new tarball soon. Please test.
RT-Send-CC: ari.jolma [...] tkk.fi, kaffeetisch [...] gmx.de
I'm working on EUMM's XS support. This EUD snippet effectively hijacks EUMM's static_lib support in order to try to fix a problem with dynamic_lib support, which seems wrong on quite a few levels. I'd like to fix this properly. Could one of you guys tell me a CPAN module (possibly yours) that breaks without this code in EUD on Win32 and MinGW, so I can fix this properly?
Subject: Re: [rt.cpan.org #45224] Fails to link against declared dependencies on strawberry perl
Date: Mon, 22 Dec 2014 12:28:18 +0100
To: bug-ExtUtils-Depends [...] rt.cpan.org
From: Torsten Schönfeld <torsten.schoenfeld [...] gmx.de>
On 22.12.2014 02:35, Ed J via RT wrote: Show quoted text
> I'd like to fix this properly. Could one of you guys tell me a CPAN > module (possibly yours) that breaks without this code in EUD on Win32 > and MinGW, so I can fix this properly?
The first few comments mention Devel::Declare and MooseX::Declare, and later on, people also state that the patch fixes the builds of Glib/Pango/Gtk2/Cairo.
On Sun Dec 21 20:35:37 2014, ETJ wrote: Show quoted text
> I'm working on EUMM's XS support. This EUD snippet effectively hijacks > EUMM's static_lib support in order to try to fix a problem with > dynamic_lib support, which seems wrong on quite a few levels.
I agree the cleaner solution would be to override dynamic_lib instead of static_lib. Leon