apparently no XS modules build when linking statically #12382

p5pRT · 2012-09-06T11:12:12Z

Migrated from rt.perl.org#114774 (status was 'open')

Searchable as RT114774$

p5pRT · 2012-09-06T11:12:13Z

From perl@plan9.de

Created by perl@plan9.de

As the subject says, when perl is cofnigured with static linking, I have yet to find an XS module
that actually builds:

As a simple example, Params::Validate (which does not supply a Makefile.PL).

# $PERL Build.PL
ld: warning: cannot find entry symbol _start; defaulting to 08048080
Creating new 'MYMETA.yml' with configuration results
Creating new 'Build' script for 'Params-Validate' version '1.06'
# ./Build
Building Params-Validate
ccache gcc -Ic -I/tmp/testperl/perl/lib/CORE -DXS_VERSION="1.06" -DVERSION="1.06" -c -g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 -o lib/Params/Validate/XS.o lib/Params/Validate/XS.c
ExtUtils::Mkbootstrap::Mkbootstrap('blib/arch/auto/Params/Validate/XS/XS.bs')
ld -o blib/arch/auto/Params/Validate/XS/XS.none lib/Params/Validate/XS.o
ld: warning: cannot find entry symbol _start; defaulting to 08048080
lib/Params/Validate/XS.o: In function `article':
/tmp/testperl/cpan/build/Params-Validate-1.06-N3FOvY/lib/Params/Validate/XS.xs:213: undefined reference to `Perl_sv_2pv_flags'
lib/Params/Validate/XS.o: In function `merge_hashes':
/tmp/testperl/cpan/build/Params-Validate-1.06-N3FOvY/lib/Params/Validate/XS.xs:691: undefined reference to `Perl_hv_iterinit'
/tmp/testperl/cpan/build/Params-Validate-1.06-N3FOvY/lib/Params/Validate/XS.xs:693: undefined reference to `Perl_hv_common'
/tmp/testperl/cpan/build/Params-Validate-1.06-N3FOvY/lib/Params/Validate/XS.xs:692: undefined reference to `Perl_hv_iternext_flags'

(many missing symbols omitted)

error building blib/arch/auto/Params/Validate/XS/XS.none from lib/Params/Validate/XS.o at /tmp/testperl/perl/lib/ExtUtils/CBuilder/Base.pm line 241.

Modules that use a traditional Makefile.PL are not affected (even when
they use Module::Build to generate a Makefile.PL):

Checking if your kit is complete...
Looks good
Writing Makefile for JSON::XS
Writing MYMETA.yml and MYMETA.json
cp XS/Boolean.pm blib/lib/JSON/XS/Boolean.pm
cp XS.pm blib/lib/JSON/XS.pm
/tmp/testperl/perl/bin/perl /tmp/testperl/perl/lib/ExtUtils/xsubpp -typemap /tmp/testperl/perl/lib/ExtUtils/typemap -typemap typemap XS.xs > XS.xsc && mv XS.xsc XS.c
ccache gcc -c -g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 -DVERSION=\"2.33\" -DXS_VERSION=\"2.33\" "-I/tmp/testperl/perl/lib/CORE" XS.c
rm -rf blib/arch/auto/JSON/XS/XS.a
/usr/bin/ar cr blib/arch/auto/JSON/XS/XS.a XS.o && : blib/arch/auto/JSON/XS/XS.a
chmod 755 blib/arch/auto/JSON/XS/XS.a
cp bin/json_xs blib/script/json_xs
/tmp/testperl/perl/bin/perl -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/json_xs
Probably a static XS module, rebuilding perl
Writing "Makefile.aperl" for this perl
Writing Makefile.aperl for JSON::XS
Writing MYMETA.yml and MYMETA.json
make -f Makefile.aperl perl
make[1]: Entering directory `/root/src/JSON-XS'
Writing perlmain.c
cd . && ccache gcc -c "-I/tmp/testperl/perl/lib/CORE" \
-g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 \
-DVERSION=\"2.33\" \
-DXS_VERSION=\"2.33\" "-I/tmp/testperl/perl/lib/CORE" perlmain.c
ccache gcc -c -g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 -DVERSION=\"2.33\" -DXS_VERSION=\"2.33\" "-I/tmp/testperl/perl/lib/CORE" XS.c
rm -rf blib/arch/auto/JSON/XS/XS.a
/usr/bin/ar cr blib/arch/auto/JSON/XS/XS.a XS.o && : blib/arch/auto/JSON/XS/XS.a
chmod 755 blib/arch/auto/JSON/XS/XS.a
cat /tmp/testperl/perl/lib/auto/Array/Heap/extralibs.ld >> blib/arch/auto/JSON/XS/extralibs.all

(many lines omitted)

cat /tmp/testperl/perl/lib/auto/threads/extralibs.ld >> blib/arch/auto/JSON/XS/extralibs.all
cat blib/arch/auto/JSON/XS/extralibs.ld >> blib/arch/auto/JSON/XS/extralibs.all
ccache gcc -Wl,--gc-sections -Wl,--allow-multiple-definition -static -lpthread -o perl -O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 ./perlmain.o XS.o blib/arch/auto/JSON/XS/XS.a /tmp/testperl/perl/lib/auto/threads/threads.a /tmp/testperl/perl/lib/auto/threads/shared/shared.a /tmp/testperl/perl/lib/auto/re/re.a /tmp/testperl/perl/lib/auto/mro/mro.a /tmp/testperl/perl/lib/auto/attributes/attributes.a /tmp/testperl/perl/lib/auto/YAML/XS/LibYAML/LibYAML.a /tmp/testperl/perl/lib/auto/XML/Parser/Expat/Expat.a /tmp/testperl/perl/lib/auto/Unicode/Normalize/Normalize.a /tmp/testperl/perl/lib/auto/Time/Piece/Piece.a /tmp/testperl/perl/lib/auto/Time/HiRes/HiRes.a /tmp/testperl/perl/lib/auto/Text/Soundex/Soundex.a /tmp/testperl/perl/lib/auto/Term/ReadKey/ReadKey.a /tmp/testperl/perl/lib/auto/Sys/Syslog/Syslog.a /tmp/testperl/perl/lib/auto/Sys/Hostname/Hostname.a /tmp/testperl/perl/lib/auto/Storable/Storable.a /tmp/testperl/perl/lib/auto/Socket/Socket.a /tmp/testperl/perl/lib/auto/SDBM_File/SDBM_File.a /tmp/testperl/perl/lib/auto/PerlIO/via/via.a /tmp/testperl/perl/lib/auto/PerlIO/scalar/scalar.a /tmp/testperl/perl/lib/auto/PerlIO/encoding/encoding.a /tmp/testperl/perl/lib/auto/Params/Util/Util.a /tmp/testperl/perl/lib/auto/PPI/XS/XS.a /tmp/testperl/perl/lib/auto/POSIX/POSIX.a /tmp/testperl/perl/lib/auto/PApp/SQL/SQL.a /tmp/testperl/perl/lib/auto/Opcode/Opcode.a /tmp/testperl/perl/lib/auto/Net/SSLeay/SSLeay.a /tmp/testperl/perl/lib/auto/Net/Interface/Interface.a /tmp/testperl/perl/lib/auto/Math/BigInt/FastCalc/FastCalc.a /tmp/testperl/perl/lib/auto/MIME/Base64/Base64.a /tmp/testperl/perl/lib/auto/List/Util/Util.a /tmp/testperl/perl/lib/auto/List/MoreUtils/MoreUtils.a /tmp/testperl/perl/lib/auto/Linux/Inotify2/Inotify2.a /tmp/testperl/perl/lib/auto/IPC/SysV/SysV.a /tmp/testperl/perl/lib/auto/IO/IO.a /tmp/testperl/perl/lib/auto/IO/AIO/AIO.a /tmp/testperl/perl/lib/auto/I18N/Langinfo/Langinfo.a /tmp/testperl/perl/lib/auto/Hash/Util/Util.a /tmp/testperl/perl/lib/auto/Hash/Util/FieldHash/FieldHash.a /tmp/testperl/perl/lib/auto/HTML/Parser/Parser.a /tmp/testperl/perl/lib/auto/Guard/Guard.a /tmp/testperl/perl/lib/auto/Filter/Util/Call/Call.a /tmp/testperl/perl/lib/auto/File/Glob/Glob.a /tmp/testperl/perl/lib/auto/Fcntl/Fcntl.a /tmp/testperl/perl/lib/auto/Encode/Unicode/Unicode.a /tmp/testperl/perl/lib/auto/Encode/TW/TW.a /tmp/testperl/perl/lib/auto/Encode/Symbol/Symbol.a /tmp/testperl/perl/lib/auto/Encode/KR/KR.a /tmp/testperl/perl/lib/auto/Encode/JP/JP.a /tmp/testperl/perl/lib/auto/Encode/Encode.a /tmp/testperl/perl/lib/auto/Encode/EBCDIC/EBCDIC.a /tmp/testperl/perl/lib/auto/Encode/CN/CN.a /tmp/testperl/perl/lib/auto/Encode/Byte/Byte.a /tmp/testperl/perl/lib/auto/EV/Loop/Async/Async.a /tmp/testperl/perl/lib/auto/EV/EV.a /tmp/testperl/perl/lib/auto/Digest/SHA256/SHA256.a /tmp/testperl/perl/lib/auto/Digest/SHA/SHA.a /tmp/testperl/perl/lib/auto/Digest/MD6/MD6.a /tmp/testperl/perl/lib/auto/Digest/MD5/MD5.a /tmp/testperl/perl/lib/auto/Digest/MD4/MD4.a /tmp/testperl/perl/lib/auto/Devel/Peek/Peek.a /tmp/testperl/perl/lib/auto/Devel/PPPort/PPPort.a /tmp/testperl/perl/lib/auto/Devel/DProf/DProf.a /tmp/testperl/perl/lib/auto/Data/Dumper/Dumper.a /tmp/testperl/perl/lib/auto/DBI/DBI.a /tmp/testperl/perl/lib/auto/DBD/mysql/mysql.a /tmp/testperl/perl/lib/auto/Cwd/Cwd.a /tmp/testperl/perl/lib/auto/Crypt/Twofish2/Twofish2.a /tmp/testperl/perl/lib/auto/Crypt/SSLeay/SSLeay.a /tmp/testperl/perl/lib/auto/Coro/State/State.a /tmp/testperl/perl/lib/auto/Coro/EV/EV.a /tmp/testperl/perl/lib/auto/Convert/Scalar/Scalar.a /tmp/testperl/perl/lib/auto/Compress/Raw/Zlib/Zlib.a /tmp/testperl/perl/lib/auto/Compress/Raw/Bzip2/Bzip2.a /tmp/testperl/perl/lib/auto/Compress/LZF/LZF.a /tmp/testperl/perl/lib/auto/Clone/Clone.a /tmp/testperl/perl/lib/auto/B/B.a /tmp/testperl/perl/lib/auto/Async/Interrupt/Interrupt.a /tmp/testperl/perl/lib/auto/Array/Heap/Heap.a /tmp/testperl/perl/lib/CORE/libperl.a `cat blib/arch/auto/JSON/XS/extralibs.all` -lm -lcrypt
/tmp/testperl/perl/lib/CORE/libperl.a(doio.o): In function `Perl_apply':
/tmp/testperl/src/perl-5.12.4/doio.c:1867: warning: the use of OBSOLESCENT `utime' is discouraged, use `utimes'
/tmp/testperl/perl/lib/auto/POSIX/POSIX.a(POSIX.o): In function `XS_POSIX_tmpnam':
/tmp/testperl/src/perl-5.12.4/ext/POSIX/POSIX.xs:1666: warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/lib/mysql/libmysqlclient.a(my_gethostbyname.o): In function `my_gethostbyname_r':
/localvol/buildroot/output/build/mysql_client-5.1.53/libmysql/my_gethostbyname.c:44: warning: gethostbyname_r is obsolescent, use getnameinfo() instead.
/tmp/testperl/perl/lib/CORE/libperl.a(pp_sys.o): In function `Perl_pp_ghostent':
/tmp/testperl/src/perl-5.12.4/pp_sys.c:4761: warning: gethostbyaddr is obsolescent, use getaddrinfo() instead.
/tmp/testperl/perl/lib/auto/Socket/Socket.a(Socket.o): In function `XS_Socket_inet_aton':
/tmp/testperl/src/perl-5.12.4/ext/Socket/Socket.xs:236: warning: gethostbyname is obsolescent, use getnameinfo() instead.
To install the new "perl" binary, call
make -f Makefile.aperl inst_perl MAP_TARGET=perl
To remove the intermediate files say
make -f Makefile.aperl map_clean
make[1]: Leaving directory `/root/src/JSON-XS'
rm -f ./perlmain.o ./perlmain.c perl Makefile.aperl blib/arch/auto/JSON/XS/extralibs.all
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /tmp/testperl/perl/lib/auto/JSON/XS/XS.a
Appending installation info to /tmp/testperl/perl/lib/perllocal.pod

There also seems to be no easy way to build a new perl binary to install
via Module::Build. And lastly, it seems to be imppossible to write a
Makefile.PL from a Build.PL in an automated way.

It seems static linking is just one of many ways to break Module::Build's
XS building - some Xs modules using Module::Build (Alien::SDL and SDL)
basically do the whole linking themselves because of this.

I think Module::Build should be able to build XS extensions just like
MakeMaker does. If this can't be done, then there should be an automated
way to generate a working Makefile.PL file from the Build.PL file - many
extensions do not ship with a Makefile.PL anymore, and thus don't build in
many cases (native windows is an example where Module::Build also often
fails and MakeMaker succeeds).

Perl Info


Flags:
    category=library
    severity=high
    module=Module::Build


Summary of my perl5 (revision 5 version 12 subversion 4) configuration:
   
  Platform:
    osname=linux, osvers=3.2.0-3-amd64, archname=i686-linux
    uname='linux cerebro 3.2.0-3-amd64 #1 smp mon jul 23 02:45:17 utc 2012 i686 gnulinux '
    config_args='-Duselargefiles -Uuse64bitint -Dusemymalloc=n -Uusedl -Uusethreads -Uuseithreads -Uusemultiplicity -Uusesfio -Uuseshrplib -Uinstallusrbinperl -A ccflags= -g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -Dcc=ccache gcc -Doptimize=-O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2 -Dldflags= -Wl,--gc-sections -Wl,--allow-multiple-definition -static -lpthread -Dlibs=-lm -lcrypt -Dprefix=/tmp/testperl/perl -Dbin=/tmp/testperl/perl/bin -Dprivlib=/tmp/testperl/perl/lib -Darchlib=/tmp/testperl/perl/lib -Uusevendorprefix -Dsitelib=/tmp/testperl/perl/lib -Dsitearch=/tmp/testperl/perl/lib -Uman1dir -Uman3dir -Usiteman1dir -Usiteman3dir -Dpager=/usr/bin/less -Demail=Marc Lehmann <perl@plan9.de> -Dcf_email=Marc Lehmann <perl@plan9.de> -Dcf_by=Marc Lehmann <perl@plan9.de> -Duseperlio -dE'
    hint=recommended, useposix=true, d_sigaction=define
    useithreads=undef, usemultiplicity=undef
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc', ccflags ='-g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O6 -ffunction-sections -fdata-sections -finline-limit=8 -ffast-math -mno-inline-stringops-dynamically -mno-align-stringops -mno-ieee-fp -fomit-frame-pointer -march=pentium3 -mtune=core2 -mpush-args -finline-limit=8 -mtune=core2 -fno-schedule-insns2',
    cppflags='-g -DPERL_DISABLE_PMC -DPERL_ARENA_SIZE=16376 -DNO_PERL_MALLOC_ENV -D_GNU_SOURCE -DNDEBUG -static -fno-strict-aliasing -pipe '
    ccversion='', gccversion='4.6.1', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =' -Wl,--gc-sections -Wl,--allow-multiple-definition -static -lpthread '
    libpth=/lib /usr/lib
    libs=-lm -lcrypt
    perllibs=-lm -lcrypt
    libc=/lib/libc.so.0, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags=''
    cccdlflags='', lddlflags=''


Characteristics of this binary (from libperl): 
  Compile-time options: PERL_DISABLE_PMC PERL_DONT_CREATE_GVSV
                        PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO
                        USE_PERL_ATOF
  Built under linux
  Compiled at Sep  5 2012 22:59:27
  %ENV:
    PERL_MM_OPT="MAN1PODS= MAN3PODS="
    PERL_MM_USE_DEFAULT="1"
  @INC:
    /tmp/testperl/perl/lib
    .

p5pRT · 2012-09-06T14:51:19Z

From @Leont

On Thu Sep 06 04:12:13 2012, perl@plan9.de wrote:

As the subject says, when perl is cofnigured with static linking, I
have yet to find an XS module
that actually builds:

[...]

There also seems to be no easy way to build a new perl binary to
install
via Module::Build. And lastly, it seems to be imppossible to write a
Makefile.PL from a Build.PL in an automated way.

It seems static linking is just one of many ways to break
Module::Build's
XS building - some Xs modules using Module::Build (Alien::SDL and SDL)
basically do the whole linking themselves because of this.

I think Module::Build should be able to build XS extensions just like
MakeMaker does. If this can't be done, then there should be an
automated
way to generate a working Makefile.PL file from the Build.PL file -
many
extensions do not ship with a Makefile.PL anymore, and thus don't
build in
many cases (native windows is an example where Module::Build also
often
fails and MakeMaker succeeds).

First of all, you filed this bugreport at the wrong place. The upstream
for Module::Build is on CPAN, so it's CPAN bugtracker should be used.
You can find this bug at https://rt.cpan.org/Ticket/Display.html?id=47282.

Secondly, patches welcome.

Leon

p5pRT · 2012-09-06T14:51:20Z

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

p5pRT · 2012-09-06T14:59:29Z

From @nwc10

On Thu, Sep 06, 2012 at 07:51:20AM -0700, Leon Timmermans via RT wrote:

First of all, you filed this bugreport at the wrong place. The upstream
for Module::Build is on CPAN, so it's CPAN bugtracker should be used.

And frustratingly we don't (yet) have the infrastructure merged so that
it's trivial to shunt bugs across to the right place. I *think* that
there's now realistic chance of this happening, but I remain skeptical
until I've actually seen it happen.

You can find this bug at https://rt.cpan.org/Ticket/Display.html?id=47282.

Secondly, patches welcome.

Because it's unlikely to happen otherwise? I'm getting the impression from
the deathly quiet on the module build mailing list and the general growth
pattern on:

https://rt.cpan.org/Public/Dist/Display.html?Status=Active&Name=Module-Build

that Module::Build has no active developers currently. Which is a shame.

Nicholas Clark

p5pRT · 2012-09-06T15:11:16Z

From schmorp@schmorp.de

On Thu, Sep 06, 2012 at 07:51:20AM -0700, Leon Timmermans via RT <perlbug-followup@perl.org> wrote:

First of all, you filed this bugreport at the wrong place. The upstream

Hmm, perlbug said bugs against core modules should be reported via it - is
this a bug in perlbug, or is submitting bugs here the proper way to get
redirected (as it happened)?

for Module::Build is on CPAN, so it's CPAN bugtracker should be used.
You can find this bug at https://rt.cpan.org/Ticket/Display.html?id=47282.

Thanks for pointing me towards this.

Hmm, that bug seems to be about building perl (although it's not entirely
clear), this bug is about building XS modules. They are sufficiently near
that they could be combined though, thanks for pointing it out.

However, judging from the bug date, it seems Module::Build is essentially
unmaintained - while fixing it would be useful, in the end, does that
mean the correct fix for these problems would be to patch modules using
Module::Build into using something that actually works and is maintained?

Secondly, patches welcome.

Thats what you say, but my actual experience with these kind of patches
is that they are not very welcome, especially bugfixes :) I don't think
I have the time to fight a week for every single small bugfix (as in the
past), and a patch for this problem would be much larger.

Besides, one would assume that the maintainer of Module::Build would
have it much easier to fix his module, especially since a reference
implementation exists that works.

I am not saying that bugfixes don't get accepted eventually, but the path
to that _is_ expensive, and decidedly unwelcoming.

I will be happy to be of any other assistance, of course, such as making
it easy to reproduce, if somebody is interested into strating to maintain
this module again.

--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\

p5pRT · 2012-09-06T15:16:11Z

From schmorp@schmorp.de

On Thu, Sep 06, 2012 at 07:59:29AM -0700, Nicholas Clark via RT <perlbug-followup@perl.org> wrote:

https://rt.cpan.org/Public/Dist/Display.html?Status=Active&Name=Module-Build

that Module::Build has no active developers currently. Which is a shame.

Indeed, it is a shame - many people fell for the promises of Module::Build,
and I got the impression that for module authors it does improve things.

Unfortunately, for the people actually building the modules, Module::Build
has been a constant nightmare (I well remember the two year hiatus of
nobody being able to build SDL on windows after it was converted to use
Module::Build).

If it's indeed unmaintained (it looks like it is), then maybe it should be
officially deprecated, because it won't get any better, and it keeps luring
module authors into using it.

--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\

p5pRT · 2012-09-06T15:58:05Z

From @Leont

On Thu, Sep 6, 2012 at 5:10 PM, Marc Lehmann <schmorp@schmorp.de> wrote:

However, judging from the bug date, it seems Module::Build is essentially
unmaintained - while fixing it would be useful, in the end, does that
mean the correct fix for these problems would be to patch modules using
Module::Build into using something that actually works and is maintained?

Incidentally ExtUtils::MakeMaker has a longer list of open issues than
Module::Build does, and has seen less frequent releases lately.
Module::Build is very much undermaintained, but that goes for much of
the toolchain. I'm still fixing bugs that annoy me, but I can't fix
everybody's bugs.

Thats what you say, but my actual experience with these kind of patches
is that they are not very welcome, especially bugfixes :) I don't think
I have the time to fight a week for every single small bugfix (as in the
past), and a patch for this problem would be much larger.

Well, I'm currently the sucker who accepts and releases patches, and
have done both as recent as last week, though thinking about it the
real fix would probably involve ExtUtils::CBuilder anyway, which does
have core as its upstream.

Besides, one would assume that the maintainer of Module::Build would
have it much easier to fix his module, especially since a reference
implementation exists that works.

I suspect you have more recent experience with static perls than
anyone else here. It has kind of gone out of fashion for most
purposes. sub makeaperl in ExtUtils::MM_Unix is your friend. It's a
reference implementation that contains a lot of heavy wizardry, I'm
afraid.

Leon

p5pRT · 2012-09-06T16:01:13Z

From @Leont

On Thu, Sep 6, 2012 at 5:15 PM, Marc Lehmann <schmorp@schmorp.de> wrote:

Indeed, it is a shame - many people fell for the promises of Module::Build,
and I got the impression that for module authors it does improve things.

Unfortunately, for the people actually building the modules, Module::Build
has been a constant nightmare (I well remember the two year hiatus of
nobody being able to build SDL on windows after it was converted to use
Module::Build).

If it's indeed unmaintained (it looks like it is), then maybe it should be
officially deprecated, because it won't get any better, and it keeps luring
module authors into using it.

Module::Build was a really good idea, but poorly implemented. My long
term solution would be to write a better pure-perl install-tool that
doesn't suffer from M::B's architectural issues. Work in progress.

Leon

p5pRT · 2012-09-07T03:13:31Z

From schmorp@schmorp.de

On Thu, Sep 06, 2012 at 05:57:00PM +0200, Leon Timmermans <fawaka@gmail.com> wrote:

Incidentally ExtUtils::MakeMaker has a longer list of open issues than
Module::Build does, and has seen less frequent releases lately.

Well, that would indeed mean that length of open bugs is no good
indication. However, Module::Build is in a very unfinished state
(witnessed by the fatc that it has enourmous trouble building modules in
many environments where makemaker works), and the problems with it are far
larger than the problems with makemaker, which generally works as expected
by perl (mostly because it is the standard).

Of course, there is also the design problem with Module::Build - it
doesn't allow for corrections, that is, if a compiler switch is wrong in a
MakeMaker created Makefile you can just edit it, while with Module::Build,
you are out of luck (I once tried to trace through Module::Build to fix
parameter generation, but the total lack of documentation on how it'S
submodules actually work made me fail :)

This means that Module::Build must be held to a higher standard than
makemaker - minor issues with makemaker can easily be fixed manually, or
even automatically, while the same minor issues with Module::Build are
essentially unfixable.

the toolchain. I'm still fixing bugs that annoy me, but I can't fix
everybody's bugs.

I'm not asking you to fix my bugs btw. (and this is not my bug, a lot of
people have this problem, I being the exeption - I merely reported it
because I see it a lot and it was easy to reproduce for me).

Reporting bugs also fulfills a documentation role for others, so an open
patchless bug is still useful, if only to refer people to this "known
issue" for example.

I suspect you have more recent experience with static perls than
anyone else here. It has kind of gone out of fashion for most
purposes. sub makeaperl in ExtUtils::MM_Unix is your friend. It's a

Again, this is not about static perls, but static building of
extensions. The fact that Module::Build cannot build a perl binary is
unrelated (and could be worked around).

The problem I reported is that Module::Build can't build XS modules _at
all_ when extensions are build statically. And this cannot be worked
around easily, because to build a perl (by whatever means) you first need
to build the extension, and that already fails.

purposes. sub makeaperl in ExtUtils::MM_Unix is your friend. It's a
reference implementation that contains a lot of heavy wizardry, I'm
afraid.

Building perl is not hard at all, as all the support infrastructure for
that already exists, and it can be done independently of Module::Build
(or ExtUtils::MakeMaker). At least, I do this a lot both manually and
semi-automatically, and the same problem is presenting itself when
embedding perl (which I do very often).

The problem is really that Module::Build can't even build the module itself.
Creating a new perl doesn't enter the picture at that point.

That's why I said that the bug is not quite the same. The rt bug is about a
missing feature, this bug is about a fatal bug in Module::Build itself.

--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\

p5pRT · 2012-09-07T03:19:19Z

From schmorp@schmorp.de

On Thu, Sep 06, 2012 at 06:00:03PM +0200, Leon Timmermans <fawaka@gmail.com> wrote:

If it's indeed unmaintained (it looks like it is), then maybe it should be
officially deprecated, because it won't get any better, and it keeps luring
module authors into using it.

Module::Build was a really good idea, but poorly implemented. My long
term solution would be to write a better pure-perl install-tool that
doesn't suffer from M::B's architectural issues. Work in progress.

If I might weigh in a bit from the user side of things - please make
sure you write out some kind of intermediate form (i.e. a makefile, or
something equivalent that contains the instructions to build the module
itself). Often these days perl is built by other people than the ones
installing modules, and things can subtly change between build machine and
install machine, and especially on exotic platforms it might not be easy
(or even possible) to rebuild perl properly. An example would be to build
a module compatible with strawberry perl or activesttae perl on windows,
both of which have large idiosynchrasies, and it's often impossible to
duplicate their build environment (for example, strawberry perl might link
against multiple incompatible c libraries on the build machine, which is
broken, but you still might be forced to somehow build a module comatible
with it).

On the other hand, the ability to build a new perl binary is not something
I expect from a module installer, it should be available completely
independently (and as far as I am concerned, it already is).

--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\

p5pRT · 2012-09-07T16:13:56Z

From @Leont

On Fri, Sep 7, 2012 at 5:12 AM, Marc Lehmann <schmorp@schmorp.de> wrote:

Well, that would indeed mean that length of open bugs is no good
indication. However, Module::Build is in a very unfinished state
(witnessed by the fatc that it has enourmous trouble building modules in
many environments where makemaker works), and the problems with it are far
larger than the problems with makemaker, which generally works as expected
by perl (mostly because it is the standard).

True. I wasn't saying Module::Build is in a better state than
ExtUtils::MakeMaker, I'm saying it's not unique in its shortage of
maintenance.

Of course, there is also the design problem with Module::Build - it
doesn't allow for corrections, that is, if a compiler switch is wrong in a
MakeMaker created Makefile you can just edit it, while with Module::Build,
you are out of luck (I once tried to trace through Module::Build to fix
parameter generation, but the total lack of documentation on how it'S
submodules actually work made me fail :)

I know :-(. Actually, I think the real problem is mostly in
ExtUtils::CBuilder. It's a piece of crap that does exactly what its
author needed it to do, but falls on its mouth whenever you're trying
to go beyond that. I don't think it's salvageable.

Again, this is not about static perls, but static building of
extensions. The fact that Module::Build cannot build a perl binary is
unrelated (and could be worked around).

The problem I reported is that Module::Build can't build XS modules _at
all_ when extensions are build statically. And this cannot be worked
around easily, because to build a perl (by whatever means) you first need
to build the extension, and that already fails.

[...]

That's why I said that the bug is not quite the same. The rt bug is about a
missing feature, this bug is about a fatal bug in Module::Build itself.

I see, I didn't know that.

Leon

p5pRT added Severity High distro-Linux type-library labels Oct 19, 2019

xenu removed the Severity High label Nov 19, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

apparently no XS modules build when linking statically #12382

apparently no XS modules build when linking statically #12382

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

p5pRT commented Sep 7, 2012

p5pRT commented Sep 7, 2012

p5pRT commented Sep 7, 2012

apparently no XS modules build when linking statically #12382

apparently no XS modules build when linking statically #12382

Comments

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

From perl@plan9.de

Created by perl@plan9.de

p5pRT commented Sep 6, 2012

From @Leont

p5pRT commented Sep 6, 2012

p5pRT commented Sep 6, 2012

From @nwc10

p5pRT commented Sep 6, 2012

From schmorp@schmorp.de

p5pRT commented Sep 6, 2012

From schmorp@schmorp.de

p5pRT commented Sep 6, 2012

From @Leont

p5pRT commented Sep 6, 2012

From @Leont

p5pRT commented Sep 7, 2012

From schmorp@schmorp.de

p5pRT commented Sep 7, 2012

From schmorp@schmorp.de

p5pRT commented Sep 7, 2012

From @Leont