develooper Front page | perl.perl5.porters | Postings from November 2014

Re: Test farm

Thread Previous
From:
H.Merijn Brand
Date:
November 3, 2014 08:23
Subject:
Re: Test farm
Message ID:
20141103092334.2fdb7f49@pc09.procura.nl
On Mon, 3 Nov 2014 08:53:20 +0100, "H.Merijn Brand"
<h.m.brand@xs4all.nl> wrote:

> On Mon, 27 Oct 2014 16:23:27 -0200, "Vincent Pit (VPIT)"
> <perl@profvince.com> wrote:
> 
> > > That implies that every new build will be 64bit
> > >
> > > What would be most useful ...
> > >
> > > 1. Rebuild all builds for 64bit (will take a while)
> 
> Started this.
> 
> I am unable to build older than 5.6.0
> No idea yet if that is Devel::PatchPerl's fault or due to system
> configuration. Building 96 perls + minimum additions for testing takes
> a bit
> 
> I have now rebuilt all unthreaded 64bitall versions and am in the
> process of adding minimal extensions from CPAN (DBI, Data::Peek,
> Test::Warnings ...)
> 
> When all of that is done, I'll redo for threaded 64all longdouble
> 
> When all of that is done, I'll sync to dromedary
> 
> > > 2. Find a way to build 32bit versions on a native 64bit machine. This I
> > >     never tried, as my laptop was 32bit and the default was to build
> > >     32bit.
> > >
> > > Doing 2. will also mean I have to chase whatever 32bit libs were used
> > > and replaced with 64bit versions in the upgrade process without
> > > installing the -32bit counterpart.
> > >
> > > Doing neither will render the farm less useless as - at least IMHO -
> > > 64bit builds cannot be compared to 32bit builds on the same arch
> > >
> > > Opinions welcome
> > 
> > In the past, I tried to use your farm on dromedary to build some XS 
> > modules, but if my memories don't fool me it failed exactly because of 
> > this 32bits/64bits mismatch. So I believe 1°) would be more useful in 
> > the long run.
> 
> Just dropping all effort put in the 32bit versions seems like a waste
> of effort. I want to see if it is possible to "move" them.
> 
> I tried moving /media/Tux/perls to /media/Tux/perls-32 and I am well
> aware that that would not run out-of the box as planned. Some parts of
> the "PATH" are hardwired. Some of those parts are easy to fix. Like
> perl -pi on all .packlist files (which have no impact on runtime). That
> leaves me with these files for 5.20.1:
> 
> /media/Tux/perls-32/lib $ grep -alr /media/Tux/perls {,site_perl/}5.20.1 | fgrep -v .packlist
> 5.20.1/i686-linux-64int/Config_heavy.pl
> 5.20.1/i686-linux-64int/CORE/libperl.a
> 5.20.1/i686-linux-64int/CORE/config.h
> 5.20.1/i686-linux-64int/perllocal.pod
> 5.20.1/i686-linux-64int/Config.pm
> 5.20.1/CPAN/Config.pm
> site_perl/5.20.1/i686-linux-64int/auto/DBI/DBI.so
> 
> Again, a perl -pi on Config_heavy.pl, config.h, perllocal.pod and
> both Config.pm will reduce that, but that will NOT fix hardwired
> dependencies in perllib.a and DBI.so
> 
> Is this a blocker, and do I just rm -rf the 32bit tree or is there a
> workaround to extend the perl test farm?

/media/Tux/perls-32/lib $ strings 5.20.1/i686-linux-64int/CORE/libperl.a | grep /media/Tux/perls
/media/Tux/perls/lib/site_perl/5.20.1/i686-linux-64int
/media/Tux/perls/lib/site_perl/5.20.1
/media/Tux/perls/lib/5.20.1/i686-linux-64int
/media/Tux/perls/lib/5.20.1

as i686-linux-64int != x86_64-linux I can made sym-links and pray the
mix runs smooth

That also "fixes" DBI.so's issue

/media/Tux/perls-32/lib $ strings site_perl/5.20.1/i686-linux-64int/auto/DBI/DBI.so | grep /media/Tux
/media/Tux/perls/lib/5.20.1/i686-linux-64int/CORE/inline.h

Same for threaded perl when I'm ready with that part.
Do I have to expect trouble?

-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.21   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About