Problems installing Devel::Cover on Strawberry, seems to work on Cygwin

[jplindstrom]

I just tried to install Devel::Cover on my home box running WinXP and Strawberry Perl 5.8.8. It failed with:

C:\DOCUME~1\linjoh\LOCALS~1\Temp\cpan\build\Devel-Cover-0.63>g++ -o bl
+ib\arch\auto\Devel\Cover\Cover.dll -Wl,-
-base-file -Wl,dll.base -mdll -s -L"c:\strawberry-perl\perl\lib\CORE" 
+-L"c:\strawberry-perl\mingw\lib" Cover.o
 -Wl,--image-base,0x31410000  C:\strawberry-perl\perl\lib\CORE\libperl
+58.a -lmsvcrt -lmoldname -lkernel32 -lus
er32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -lolea
+ut32 -lnetapi32 -luuid -lws2_32 -lmpr -l
winmm -lversion -lodbc32 -lodbccp32 dll.exp
Cover.o:Cover.c:(.text+0x2002): undefined reference to `Perl_pp_nextst
+ate'
Cover.o:Cover.c:(.text+0x2050): undefined reference to `Perl_pp_nextst
+ate'
Cover.o:Cover.c:(.text+0x20c2): undefined reference to `Perl_pp_setsta
+te'
Cover.o:Cover.c:(.text+0x2110): undefined reference to `Perl_pp_setsta
+te'
Cover.o:Cover.c:(.text+0x2182): undefined reference to `Perl_pp_dbstat
+e'
Cover.o:Cover.c:(.text+0x21d0): undefined reference to `Perl_pp_dbstat
+e'
Cover.o:Cover.c:(.text+0x2237): undefined reference to `Perl_pp_enters
+ub'
Cover.o:Cover.c:(.text+0x2270): undefined reference to `Perl_pp_enters
+ub'
Cover.o:Cover.c:(.text+0x22d7): undefined reference to `Perl_pp_cond_e
+xpr'
Cover.o:Cover.c:(.text+0x2377): undefined reference to `Perl_pp_and'
Cover.o:Cover.c:(.text+0x2417): undefined reference to `Perl_pp_andass
+ign'
Cover.o:Cover.c:(.text+0x24b7): undefined reference to `Perl_pp_or'
Cover.o:Cover.c:(.text+0x2557): undefined reference to `Perl_pp_orassi
+gn'
Cover.o:Cover.c:(.text+0x25f7): undefined reference to `Perl_pp_xor'
Cover.o:Cover.c:(.text+0x2697): undefined reference to `Perl_pp_requir
+e'
Cover.o:Cover.c:(.text+0x2737): undefined reference to `Perl_pp_exec'
collect2: ld returned 1 exit status

This is the same error CPAN testers see. But looking at the CPAN Testers Matrix says it seem to work on Cygwin, at least some of the time.

And, ack'ing through my cygwin perl directory shows that these symbols are present in:

Binary file 5.8\cygwin\CORE\libperl.a matches
Binary file 5.8\cygwin\CORE\libperl.dll.a matches

But ack'ing the Strawberry installation only matches header files (as with Cygwin). No match on .\lib\CORE\libperl58.a (or ./bin/perl58.dll?) where I suppose it would go if exported.

So, could this be because of the way Strawberry Perl is built? Is there some way to have it export those symbols similar to what Cygwin does?

Looking at the diff between my configuration and a working Cygwin Perl configuration, there are two ld flags that look promising (-Wl,--export-all-symbols and -Wl,--enable-auto-import).

I won't build a new Perl right now (getting a bit late), but maybe someone with a bit more clue can give me a hint on whether this sounds like the way to go?

Thanks,

/J

[BrowserUk]

The probability is that the undefined symbols are not exported because they do not appear in the EXPORTS section of win32\perldll.def. They do not appear there because they are not considered a part of the official PerlApi and not intended for use by code outside of the core.

Under *nix/cygwin, all symbols in a .so are exported by default because there is no mechanism to prevent it. As win32 has a mechanism to prevent the exporting of symbols from .dlls, it is used.

Hence, code that subverts the official API set, builds under *nix/cygwin but not under win32. If you could persuade the p5p guys to export all the symbols in perl5x.dll, regardless of it's official API status, about 90% of the "builds fine on *nix, but not on windoze" problems would disappear over night.

[syphilis]

If you could persuade the p5p guys to export all the symbols in perl5x.dll, regardless of it's official API status ...

It won't be easy to persuade them to do that. It amounts to convincing them that they should introduce a bug into Windows, just because that bug exists on *nix.

Cheers,
Rob

[BrowserUk]

Dropping the overzealous enforcement of an arbitrary division doesn't constitute "a bug".

Enabling code to work, with the caveat that it may fail at some point in the future if it becomes necessary to modify the APIs it utilises, for CORE reasons, is simply pragmatic.

[adamk]

And if someone can give ME a clue before the end of the weekend, I'll see what I can do about enabling those flags in the new April Strawberry by default.

[jplindstrom]

I just built a Perl 5.10 with the link flags added to makefile.mk, but that didn't solve the problem with Devel::Cover.

What did work was to add the following symbols to global.sym (two more than mentioned above):

Perl_pp_nextstate
Perl_pp_nextstate
Perl_pp_setstate
Perl_pp_setstate
Perl_pp_dbstate
Perl_pp_dbstate
Perl_pp_entersub
Perl_pp_entersub
Perl_pp_cond_expr
Perl_pp_and
Perl_pp_andassign
Perl_pp_or
Perl_pp_orassign
Perl_pp_xor
Perl_pp_require
Perl_pp_exec
Perl_pp_dor
Perl_pp_dorassign

This may be wrong way to do this since the comment at the top of global.sym says it's auto generated by "make regen_headers". However there doesn't seem to be a make target for that, so I don't know. It's a workaround for this particular module anyway.

Now, whether this is a good idea or not, I can't tell you. I have no clue about those issues.

I do know, however, that I would very, very much like Devel::Cover to build on Windows.

/J

[syphilis]

What did work was to add the following symbols to global.sym ....

Seems that's one way to make those symbols public. Nice hack - though if you ever need to access a different private symbol, you'll have to rebuild perl again.

I'm curious to know whether the Devel::Cover that you built with this hacked perl-5.10.0 will work on an unhacked perl-5.10.0. (Others would probably know the answer to that without needing to test it.) Have you tried that out ? If it works on the unhacked version of perl, then it could be handy for others if the binary of your build of Devel::Cover (either ppm package or just a tar.gz of blib) was made available.

Cheers,
Rob

[jplindstrom]

Well, adding the -Wl,--export-all-symbols option to ld sounds very promising I think, considering that it does work on Cygwin, and that that's one of the config diffs betwen Cygwin and Strawberry.

I don't know how easy it would be to test that with Perl::Dist (which is the builder of Strawberry, no?), but presumably not very.

/J