Bug #78307 for Prima: Win32, 32-bit perls need Prima.a to be renamed to libPrima.a

Wed Jul 11 05:19:47 2012 sisyphus [...] cpan.org - Ticket created

Subject:

Win32, 32-bit perls need Prima.a to be renamed to libPrima.a

Hi Dmitry, I don't know why it is so, but unless the Prima import lib is named libPrima.a, PDL::Drawing::Prima fails to build successfully. The Prima.dll that it builds wants to load a (non-existent) dll.exp.dll, instead of Prima's Prima.dll. I find this is the case for perls ranging from 5.8.0, right through to 5.16.0. A patch to the Prima-1.34 Makefile.PL that attends to this is attached. The patch also means that the 64-bit import library will be named libPrima.a. Although there appears to be no problem with an import lib named Prima.a for the 64-bit builds, they're equally content with a "libPrima.a" ... so, for consistency, why not have them the same. I'm not entirely sure that it should be up to Prima to fix this ... but I think that fixing it in the Prima source is the *simplest* way of addressing the problem. Cheers, Rob

Subject:

diff.txt

--- Makefile.PL_orig 2012-06-01 15:51:09 +1000 +++ Makefile.PL_new 2012-07-11 19:18:09 +1000 @@ -76,6 +76,7 @@ %passthru_options $Win32 $Win64 + $mingw $OS2 $unix $cygwin @@ -208,6 +209,7 @@ if ( $^O =~ /mswin32/i) { $Win32 = 1; $platform = 'win32'; + $mingw = 1 if $Config{cc} =~ /\bgcc/; } elsif ( $^O =~ /cygwin/i) { if ( $cmd_options{CYGWIN_X11}) { $unix = 1; @@ -358,7 +360,7 @@ $DEFFILE = 'Prima.def'; $LIB_EXT = ($cygwin ? '.dll' : '') . $Config{ _a}; - $LIB_PREFIX = $cygwin ? 'lib' : ''; + $LIB_PREFIX = $cygwin || $mingw ? 'lib' : ''; open F, 'Prima.pm' or die "Cannot open Prima.pm:$!\n"; my ($ver1, $ver2);

Wed Jul 11 14:51:05 2012 KARASIK [...] cpan.org - Correspondence added

Hi, I just tried the patch and it doesn't seem to produce libPrima.a, Prima.a is still generated. I wonder how did your setup manage to generate libPrima.a if the line producing it ( inside sub dynamic_lib, "$win32_use_dlltool -l \$(INST_STATIC)" ) was unchanged. Otherwise I think you've raised a valid concern, if mingw by default expects 'lib' prefix, then Prima is better to make that happen. Even though PDL::Drawing::Prima's invocation of Prima.a is wrong (David is parsing Prima::Config{dlname} where just adding Prima::Config{libs} would be enough), there's in general nothing bad in assuming that -lPrima works, win32 or not, and I'd rather have it that way, even though it won't work for non-gcc setups. So I've just made the change so libPrima.a is made on my strawberry (I don't have access now, and for two weeks for anything else), but I can't check PDL::Drawing::Prima because it fails on the compilation stage. But you're welcome to pull it from github and I'd be grateful if you could check it against your range of perls. Also I think it would be more appropriate to submit the bug to PDL::Drawing::Prima so David makes something with win32 setups.

Wed Jul 11 14:51:06 2012 The RT System itself - Status changed from 'new' to 'open'

Wed Jul 11 22:50:52 2012 sisyphus [...] cpan.org - Correspondence added

On Wed Jul 11 14:51:05 2012, KARASIK wrote: Show quoted text

> Hi, > > I just tried the patch and it doesn't seem to produce libPrima.a, > Prima.a is still generated. I wonder how did your setup manage to > generate libPrima.a if the line producing it ( inside sub dynamic_lib, > "$win32_use_dlltool -l \$(INST_STATIC)" ) was unchanged.

Duh!! You're right - it was merely another hack in my build script (which I forgot to disable) that was creating the "libPrima.a". Anyway, your github version is fine for me - produces libPrima.a, and PDL::Drawing::Prima builds fine against it. To this stage I've only tested for perl-5.14.0 (both 32-bit and 64-bit). I'll check the other versions later. I don't expect any problems with them - but I'll let you know if any problem comes up. Show quoted text

> > Otherwise I think you've raised a valid concern, if mingw by default > expects 'lib' prefix, then Prima is better to make that happen.

Well ... I don't know exactly what's going on. My 64-bit builds are quite happy with "Prima.a", and my 32-bit MinGW ought to accept "Prima.a" as well. In fact, it clearly does find Prima.a (otherwise there'd either be an error about an unfound library, or some undefined reference errors). It's just that the Prima.dll that PDL::Drawing::Prima creates wants to load a non-existent dll.exp.dll instead of the Prima.dll that it needs to load, I *think* the problem might be related to the fact that there are two "Prima.dll" files - there's the one built by Prima itself, and the one built by PDL::Drawing::Prima. In other words, I suspect that if PDL::Graphics::Prima were renamed to (say) PDL::Drawing::UsePrima, then there would be no problem in linking to "Prima.a". Show quoted text

> Even > though PDL::Drawing::Prima's invocation of Prima.a is wrong (David is > parsing Prima::Config{dlname} where just adding Prima::Config{libs} > would be enough), there's in general nothing bad in assuming that > -lPrima works, win32 or not, and I'd rather have it that way, even > though it won't work for non-gcc setups.

He might be doing something unnecessary, but he's coming up with the '-lPrima' link, which is the right result I think. Show quoted text

> Also I think it would be more appropriate to submit the bug to > PDL::Drawing::Prima so David makes something with win32 setups.

I'll recommend to David that he view this thread - though I don't really think it's a PDL::Drawing::Prima bug. Nor do I think it's a Prima bug - it just seems easiest to fix from within Prima. Cheers, Rob

Thu Jul 12 00:10:55 2012 KARASIK [...] cpan.org - Correspondence added

Show quoted text

> Anyway, your github version is fine for me - produces libPrima.a, and > PDL::Drawing::Prima builds fine against it.

That's nice to know, my PDL::Drawing::Prima builds also fine now. Show quoted text

> To this stage I've only tested for perl-5.14.0 (both 32-bit and 64-bit). > I'll check the other versions later. I don't expect any problems with > them - but I'll let you know if any problem comes up.

Thank you, that'd be great! Show quoted text

> Well ... I don't know exactly what's going on. My 64-bit builds are > quite happy with "Prima.a", and my 32-bit MinGW ought to accept > "Prima.a" as well.

I guess it is one of those little compromises went wrong that MinGW devs accepted while porting gcc to win32. I mean that in MinGW one can link to native win32 .lib files which are same format as .a anyway but without lib prefix (i.e. -lgdi32 and gdi32.lib in command line to gcc would be the same). BTW by saying "my builds" are you referring to PDL::Drawing::Prima or something else? I'm asking because PDL::Drawing::Prima is not the only module using Prima.a, I'm more-ore-less regularly testing IPA and Prima-OpenGL and Prima-Image-Magick and PDL-Prima-Image, all of them though written with Makefile.PL, not Build.PL . Show quoted text

> I *think* the problem might be related to the fact that there are two > "Prima.dll" files - there's the one built by Prima itself, and the one > built by PDL::Drawing::Prima.

It could be so, actually. upd: i'll cc this to David

Thu Jul 12 05:57:09 2012 KARASIK [...] cpan.org - Status changed from 'open' to 'resolved'

Thu Jul 12 14:39:09 2012 DCMERTENS [...] cpan.org - Correspondence added

On Thu Jul 12 00:10:55 2012, KARASIK wrote: Show quoted text

> > Anyway, your github version is fine for me - produces libPrima.a, and > > PDL::Drawing::Prima builds fine against it.

> > That's nice to know, my PDL::Drawing::Prima builds also fine now. >

> > To this stage I've only tested for perl-5.14.0 (both 32-bit and 64-bit). > > I'll check the other versions later. I don't expect any problems with > > them - but I'll let you know if any problem comes up.

> > Thank you, that'd be great! >

> > Well ... I don't know exactly what's going on. My 64-bit builds are > > quite happy with "Prima.a", and my 32-bit MinGW ought to accept > > "Prima.a" as well.

> > I guess it is one of those little compromises went wrong that MinGW devs > accepted while porting gcc to win32. I mean that in MinGW one can link > to native win32 .lib files which are same format as .a anyway but > without lib prefix (i.e. -lgdi32 and gdi32.lib in command line to gcc > would be the same). > > BTW by saying "my builds" are you referring to PDL::Drawing::Prima or > something else? I'm asking because PDL::Drawing::Prima is not the only > module using Prima.a, I'm more-ore-less regularly testing IPA and > Prima-OpenGL and Prima-Image-Magick and PDL-Prima-Image, all of them > though written with Makefile.PL, not Build.PL . >

> > I *think* the problem might be related to the fact that there are two > > "Prima.dll" files - there's the one built by Prima itself, and the one > > built by PDL::Drawing::Prima.

> > It could be so, actually. > > upd: i'll cc this to David

The problem could very well be that I've not properly specified my linking correctly. I am open to any and all suggestions to address this. Dmitry, how many of the values in %Prima::Config::Config are consistent? I feel like there was a big change last summer, probably due to the switch from the custom Makefile.PL to the one based on ExtUtils::MakeMaker. My distribution originally was based on EU::MM but I switched to M::B when I decided to have multiple (generated) xs files. I originally copied code from the Makefile.PL file from PDL::Prima::Image, and I had to convert that to some other format when I switch to M::B. When you altered Prima::Config, I had to dig around to find a similar key for my purposes. I notice there are keys such as "ldlibpathflag" and "ldlibflag" that I would be happy to use All of that is to say that I will gladly work with another key if there's a better one! Presently, I need the include paths ($Prima::Config::Config{incpaths}) and the *path* for the library file. I currently arrive at that by munging the contents of $Prima::Config::Config{dlname}, but switching to $Prima::Config::Config{libs} gives me essentially the same thing; I have done so per your request and have pushed the results to my repository. So, at the moment, everything builds on my Windows Strawberry machine. I'll upload an update to CPAN as soon as Prima v1.35 gets to CPAN, and I'll try to include instructions for Windows users in the meantime.

Thu Jul 12 14:39:10 2012 The RT System itself - Status changed from 'resolved' to 'open'

Thu Jul 12 16:03:52 2012 DCMERTENS [...] cpan.org - Correspondence added

I've uploaded PDL::Drawing::Prima v0.06 to CPAN; it contains a warning for Windows users with a not-dev release of Prima and how to install it using cpanm. (On Linux and Mac it does not issue the warning.) Hopefully this serves as a stop-gap until Prima 1.35 hits CPAN.

Thu Jul 12 16:04:25 2012 DCMERTENS [...] cpan.org - Correspondence added

On Thu Jul 12 16:03:52 2012, DCMERTENS wrote: Show quoted text

> I've uploaded PDL::Drawing::Prima v0.06 to CPAN; it contains a warning > for Windows users with a not-dev release of Prima and how to install it > using cpanm. (On Linux and Mac it does not issue the warning.) Hopefully > this serves as a stop-gap until Prima 1.35 hits CPAN.

Sorry, my reply reopened the ticket. Closing now.

Thu Jul 12 16:58:40 2012 KARASIK [...] cpan.org - Correspondence added

Show quoted text

> Dmitry, how many of the values in %Prima::Config::Config are consistent? > I feel like there was a big change last summer, probably due to the > switch from the custom Makefile.PL to the one based on

ExtUtils::MakeMaker. I vaguely remember that although I wanted to keep Config values as much untouched as possible, I had to change some things, but not the essential ones, i.e. inc and libs . These values are specifically crafted to make it as easy as possible to build Prima-dependent modules with EU::MM (see f.ex. Prima-OpenGL/Makefile.PL). I don't have any experience with Module::Build though, so can't say much here. One of the tricks of EU:::MM is that one can say "-lPrima" even on win32 msvc compiler, and still it will be translated to a proper call to the linker. I'm saying that it would be interesting to see if you can build PDL::D::P on ActiveState with MSVC. Show quoted text

> ($Prima::Config::Config{incpaths}) and the *path* for the library file.

libs is not really path for the library file, it's rather a whole command to the linker. I just tried this: $build->extra_linker_flags($Prima::Config::Config{libs}); on PDL::D::P instead of that whole new paragraph, and it seems to be ok on strawberry. I can't check it now on other systems, but I believe that only line should be enough.

Thu Jul 12 16:58:41 2012 KARASIK [...] cpan.org - Status changed from 'open' to 'resolved'