Module::Build fails xs.t and ppm.t without dynamic loading

p5pRT commented 15 years ago

Migrated from rt.perl.org#66726 (status was 'resolved')

Searchable as RT66726$

p5pRT commented 15 years ago

From david@vulcan.hyperbolic.net

This is a bug report for perl from dagolden@cpan.org generated with the help of perlbug 1.39 running under perl 5.11.0.

----------------------------------------------------------------- Module::Build xs.t and ppm.t attempt to load an XS module\, which fails when Perl is compiled with -Uusedl.

It is documented in the M::B RT queue:

https://rt.cpan.org/Ticket/Display.html?id=46178

It is similar to this perlbug:

http://rt.perl.org/rt3/Ticket/Display.html?id=65754

It's unclear to me whether tests should just skip or be marked Todo or whether there are necessary changes to Module::Build.

I would imagine there would be similar issues with ExtUtils::MakeMaker\, except that it doesn't seem to actually attempt to load XS modules\, it only checks to see that they compiled. So on that basis\, perhaps the loading portion of M::B tests should skip as well.

Perl Info

``` Flags: category=library severity=low Site configuration information for perl 5.11.0: Configured by david at Thu Jun 18 18:05:26 EDT 2009. Summary of my perl5 (revision 5 version 11 subversion 0) configuration: Commit id: 4784c5e80ccedd3734ce162e02ed1c7e25e60c01 Platform: osname=linux, osvers=2.6.27-14-generic, archname=x86_64-linux uname='linux vulcan 2.6.27-14-generic #1 smp wed apr 15 19:29:46 utc 2009 x86_64 gnulinux ' config_args='-des -Dusedevel -Dcc=ccache cc -Uusedl' hint=recommended, useposix=true, d_sigaction=define useithreads=undef, usemultiplicity=undef useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='ccache cc', ccflags ='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.3.2', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='ld', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 libs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldb -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.8.90.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.8.90' Dynamic Linking: dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags='' cccdlflags='', lddlflags='' Locally applied patches: PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */ PERL_GIT_UNCOMMITTED_CHANGES /* do not remove this line */ @INC for perl 5.11.0: lib /usr/local/lib/perl5/site_perl/5.11.0/x86_64-linux /usr/local/lib/perl5/site_perl/5.11.0 /usr/local/lib/perl5/5.11.0/x86_64-linux /usr/local/lib/perl5/5.11.0 . Environment for perl 5.11.0: HOME=/home/david LANG=en_US.UTF-8 LANGUAGE (unset) LC_COLLATE=C LC_CTYPE=en_US.UTF-8 LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=.:/home/david/bin:/home/david/git/utility-scripts:/opt/perl/current/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games PERL_BADLANG (unset) PERL_EXTUTILS_AUTOINSTALL=--default-deps SHELL=/bin/bash ```

p5pRT commented 15 years ago

From @craigberry

On Thu\, Jun 18\, 2009 at 5:36 PM\, david@vulcan.hyperbolic.net (via RT)\perlbug\-followup@perl\.org wrote:

# New Ticket Created by david@vulcan.hyperbolic.net # Please include the string: [perl #66726] # in the subject line of all future correspondence about this issue. # \<URL: http://rt.perl.org/rt3/Ticket/Display.html?id=66726 >

This is a bug report for perl from dagolden@cpan.org generated with the help of perlbug 1.39 running under perl 5.11.0.

----------------------------------------------------------------- Module::Build xs.t and ppm.t attempt to load an XS module\, which fails when Perl is compiled with -Uusedl.

It is documented in the M::B RT queue:

https://rt.cpan.org/Ticket/Display.html?id=46178

It is similar to this perlbug:

http://rt.perl.org/rt3/Ticket/Display.html?id=65754

It's unclear to me whether tests should just skip or be marked Todo or whether there are necessary changes to Module::Build.

I would imagine there would be similar issues with ExtUtils::MakeMaker\, except that it doesn't seem to actually attempt to load XS modules\, it only checks to see that they compiled. So on that basis\, perhaps the loading portion of M::B tests should skip as well.

In principle MakeMaker knows how to link a new Perl with the new extension in it when you've built a static Perl and are building an extension with it. At which point use-ing the module should succeed because you've linked it in -- you're not actually loading it via DynaLoader because it's already there. I don't know if that's currently working or is tested anywhere\, but see L\<Static Linking of a new Perl Binary> in the MakeMaker pod.

p5pRT commented 15 years ago

The RT System itself - Status changed from 'new' to 'open'

p5pRT commented 15 years ago

From @xdg

On Sun\, Jun 21\, 2009 at 10:26 AM\, Craig A. Berry\craig\.a\.berry@gmail\.com wrote:

In principle MakeMaker knows how to link a new Perl with the new extension in it when you've built a static Perl and are building an extension with it. At which point use-ing the module should succeed because you've linked it in -- you're not actually loading it via DynaLoader because it's already there. I don't know if that's currently working or is tested anywhere\, but see L\<Static Linking of a new Perl Binary> in the MakeMaker pod.

I've seen that\, but it doesn't look like EU::MM actually tests the re-linking Perl\, but nor does it test the loading of the XS module\, so it doesn't exhibit the same behavior as M::B.

I don't know if M::B supports relinking\, but it definitely shouldn't test loading dynamically.

Tux said pretty definitively that what the M::B test was doing was wrong\, so my plan is to have that portion of the M::B tests skip when $Config{usedl} is false.

The same change should happen upstream in EU::ParseXS\, but I have co-maintainer on that so someone with access will need to make the change.

-- David

p5pRT commented 15 years ago

From @tux

On Sun\, 21 Jun 2009 10:48:04 -0400\, David Golden \xdaveg@gmail\.com wrote:

On Sun\, Jun 21\, 2009 at 10:26 AM\, Craig A. Berry\craig\.a\.berry@gmail\.com wrote:

In principle MakeMaker knows how to link a new Perl with the new extension in it when you've built a static Perl and are building an extension with it. At which point use-ing the module should succeed because you've linked it in -- you're not actually loading it via DynaLoader because it's already there. I don't know if that's currently working or is tested anywhere\, but see L\<Static Linking of a new Perl Binary> in the MakeMaker pod.

I've seen that\, but it doesn't look like EU::MM actually tests the re-linking Perl\, but nor does it test the loading of the XS module\, so it doesn't exhibit the same behavior as M::B.

I don't know if M::B supports relinking\, but it definitely shouldn't test loading dynamically.

Tux said pretty definitively that what the M::B test was doing was wrong\,

I might be right\, but when I was saying that some test was definitively wrong\, I was referring to a test in SQL::Statement\, not something in M::B. I'm sorry you understood it differently

so my plan is to have that portion of the M::B tests skip when $Config{usedl} is false.

The same change should happen upstream in EU::ParseXS\, but I have co-maintainer on that so someone with access will need to make the change.

-- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using & porting perl 5.6.2\, 5.8.x\, 5.10.x\, 5.11.x on HP-UX 10.20\, 11.00\, 11.11\, 11.23\, and 11.31\, OpenSuSE 10.3\, 11.0\, and 11.1\, AIX 5.2 and 5.3. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

p5pRT commented 15 years ago

From @xdg

On Sun\, Jun 21\, 2009 at 11:17 AM\, H.Merijn Brand\h\.m\.brand@xs4all\.nl wrote:

Tux said pretty definitively that what the M::B test was doing was wrong\,

I might be right\, but when I was saying that some test was definitively wrong\, I was referring to a test in SQL::Statement\, not something in M::B. I'm sorry you understood it differently

I'm not letting you off the hook so easily. Since no one else has anything definitive to say about the issue\, you being definitive in a way I can conveniently misinterpret is enough justification for me. ;-)

-- David

p5pRT commented 11 years ago

From @jkeenan

On Thu Jun 18 15:36:24 2009\, david@vulcan.hyperbolic.net wrote:

Reviewed this 3-1/2-year-old ticket tonight.

This is a bug report for perl from dagolden@cpan.org generated with the help of perlbug 1.39 running under perl 5.11.0.

----------------------------------------------------------------- Module::Build xs.t and ppm.t attempt to load an XS module\, which fails when Perl is compiled with -Uusedl.

It is documented in the M::B RT queue:

https://rt.cpan.org/Ticket/Display.html?id=46178

That ticket has been marked Resolved.

It is similar to this perlbug:

http://rt.perl.org/rt3/Ticket/Display.html?id=65754

... as has that ticket.

It's unclear to me whether tests should just skip or be marked Todo or whether there are necessary changes to Module::Build.

I would imagine there would be similar issues with ExtUtils::MakeMaker\, except that it doesn't seem to actually attempt to load XS modules\, it only checks to see that they compiled. So on that basis\, perhaps the loading portion of M::B tests should skip as well.

David\, is this ticket closable?

Thank you very much. Jim Keenan

p5pRT commented 11 years ago

@xdg - Status changed from 'open' to 'resolved'

Perl / perl5