perl5.18.0 build-config seems to ignore some 64-bit types #13216
Comments
From perl-diddler@tlinx.orgCreated by perl-diddler@tlinx.orgI know that some people manage to get this to build on SuSE, but I.e: Ishtar:packages/build/perl-5.18> make |& tee ../../logs/perl518-a.log There were other compile warnings based on unused return values but the above error ends the build. It's *as if* (and this makes it look related, maybe? to previous bug regarding mmap?) perl is using a 32-bit int to hold what should be The build doesn't get any farther than this when run single-job. The config line I used coming into this was: Ishtar:packages/build/perl-5.18> ./configure.gnu --prefix=/usr -Dvendorprefix=/usr -Dinstallusrbinperl -Dusethreads -Dlibswanted="gdbm gdbm_compat" -Di_db -Di_dbm -Di_ndbm -Di_gdbm -Duseshrplib=\'true\' $options |& tee perlconf.log # for options = -Doptimize='-g -ggdb -O2 -m64 -fasynchronous-unwind-tables -fbranch-target-load-optimize -fdelete-null-pointer-checks -fgcse-after-reload -fgcse-las -fgcse-sm -fgraphite-identity -fipa-pta -fivopts -floop-block -floop-flatten -floop-interchange -floop-strip-mine -flto -fmessage-length=0 -fpredictive-commoning -frename-registers -freorder-blocks-and-partition -ftree-loop-linear -ftree-loop-distribution -ftree-loop-distribute-patterns -ftree-loop-im -ftree-loop-ivcanon -ftree-vectorize -ftree-slp-vectorize -funswitch-loops -funwind-tables -fvariable-expansion-in-unroller -fvect-cost-model -fweb -march=native -Wno-unused-result -pipe' -Accflags='-DPERL_USE_SAFE_PUTENV' -Dotherlibdirs=/usr/lib/perl5/site_perl Is it just coincidence that this another place (previous (see #119475)) where perl isn't using the libc compat definition of a type in a system call? Perl Info |
From @TuxOn Fri, 30 Aug 2013 12:41:50 -0700, Linda Walsh (via RT)
Which SUSE? I might want to try to reproduce. I have (devel) acces to Linux 2.6.31.14-0.6-desktop [openSUSE 11.2 (Emerald)] 13.1 will be released in November, and it already has been tagged -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From perl-diddler@tlinx.orgOn Fri Aug 30 12:58:23 2013, hmbrand wrote:
I have factory packages from as late as June 18, installed on top of kernel info:
I usually try to keep up on a more recent vanilla kernel build than suse |
From @TuxOn Fri, 30 Aug 2013 13:10:21 -0700, "Linda Walsh via RT"
Right, so my Linux 3.7.10-1.11-desktop [openSUSE 12.3 (Dartmouth)] From scratch, without using my Policy.sh … $ wget http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.18.0.tar.bz2 If you compile perl5 on a different machine or from a different object Everything is up to date. Type 'make test' to run test suite. You had this: Where is that -m64 coming from? I see in the ticket that you set And, if you want a 64bit perl, why not do it the way installation -- |
From perl-diddler@tlinx.orgOn Fri Aug 30 13:43:04 2013, hmbrand wrote:
I know if I don't bend over backwards to get the gdbm and gdbm_compat
Unfortunately, the perl make (like most "config"-based make processes) Theoretically, if you don't have the pertinent "devel" packages loaded Starting in about SuSE 11.4 or 12.0, suse switched over to using Same goes for many other "assumed to be present" utils, though the list
The config_args from perl-V is from the perl installed on my system that I don't think the m64 is necessary and don't remember why it was there It was one of the ones I copied from the existing line that was in use ... ah , the m64 option comes, originally, from I have added to that over the years, and my opt flags looks like: optflags: -g -ggdb -O2 -m64 -fasynchronous-unwind-tables \
I would too! So I am trying to do as "SuSE suggests -- and trying to build based on That said, when I build only using the options and invocation method as The tests fail in the dbm related tests I am attaching the suse perl spec file I was using (done an rpmbuild Can provide the output from configure as well if that is of usefulness... Am going to look at why there is a difference in the 'make' for the suse |
From @doughera88On Fri, Aug 30, 2013 at 12:41:50PM -0700, Linda Walsh wrote:
This particular problem likely arose because Configure couldn't figure The fact that -DPERL_USE_SAFE_PUTENV appears 10 times suggests that In short, I can't reproduce this and really don't understand how you got I recommend the following: 1. Start with a clean source tree. 2. Figure out the *minimal* Configure command line necessary to 3. Post the *minimal* Configure command line, the *output* of the -- |
From perl-diddler@tlinx.orgOn Fri Aug 30 18:45:24 2013, doughera wrote:
That might have had to do with some excess merging of ENV var that
Everything after the 1st build was from a fresh tree. I.e when Merijin showed their sequence of untaring and building,
I wasn't sure of what the minimal files to remove were, and I also tried to build from the spec file by removing various patches Of the ones built from tar, as I mentioned in response to merijin, I was The CPAN test failures seen in the test output are relatively new and
My last built with the rpm fails here:
RPM build errors:
# This script is designed to provide a handy summary of the configuration # Note that the text lines /^Summary of/ .. /^\s*$/ are copied into !NO!SUBS! I don't know if it is worth adding in the grep for syscall stuff at this I can forget about the ".rpm" not building -- I used to build from tar The build w/o the rpm -- fresh untar gets the test results already FWIW, I find it hard to get a reliable, reproducible, controlled build, i.e. for squid, for example (with majority lines elided). #!/bin/bash With perl, I wasn't sure where, but I noticed it kept state info, so I I.e. usually I start with a clean perl-dir each build, because it ----Just so you know, I'm not kidding --- dir=${src%%.t*} log=/tmp/makeperl-$$.log { if (($status==0)) ; then echo "perl make & tested ok"; exit 0; fi echo "Bad status \"$status\" on exit" echo "Make is running. To monitor the log do:" So how should I move forward -- the DB problem has been a thorn for Thanks! ;-)
|
From @TuxOn Sat, 31 Aug 2013 21:50:44 -0700, "Linda Walsh via RT"
Shall I call you Lindia? Does this help? --8<--- INSTALL Building ODBM_File on some (Open)SUSE distributions might run into this 1. Disable the use of ODBM_FILE Configure ... -Dnoextensions=ODBM_File 2. Fix the header file, somewhat like this: --- a/usr/include/dbm.h 2010-03-24 08:54:59.000000000 +0100 extern datum nextkey __P((datum key)); -extern int dbmclose __P((DBM *)); FWIW my 12.3 has $ grep dbmclose /usr/include/dbm.h
I read the mail trice and still did not see if you tried the "minimal" unpack from tar, then e.g. $ ./Configure -Duse64bitall -des The general top-level script you are looking for to make "reliable" --8<--- INSTALL After Configure runs, it stores a number of common site-wide "policy" Alternatively, if you wish to change some or all of those policy rm -f Policy.sh to ensure that Configure doesn't re-use them. Further information is in the Policy_sh.SH file itself. If the generated Policy.sh file is unsuitable, you may freely edit it As an example, I'll share my stripped down Policy.sh which I use untar source My install location is /pro --8<--- Policy.sh # put this file in the perl source tree and run 'Configure -ds' man1dir=/pro/local/man/man1 case "$versiononly" in [ "X$OSTYPE" = "X" ] && OSTYPE="$osname" # The -DDEBUGGING part will be stripped out optionally later extras='none' libsdirs=' /lib /pro/local/lib' locincpth='/pro/local/include' awk='gawk' case "$OSTYPE" in hpux) # For Oracle, will fail without perlio in threads osf1) linux) Add as many OS's as you support this way (I stripped a few). A Policy.sh should be written to be ably to create reproducible builds. So, the way to go for you I guess is to create a Policy.sh which holds -- |
From @doughera88On Sat, Aug 31, 2013 at 09:50:44PM -0700, "Linda Walsh via RT" wrote:
I don't need to hear about 5 ways. I need to see a single way, from a [lots of irrelevant lines deleted.]
You move forward exactly as I said in my previous email. First, you provide us with the *minimal* Configure command line Second, you provide the output of the ./myconfig script from that Third, you provide the exact error messages or test failures that Only then can someone else hope to understand your problem, try to -- |
From perl-diddler@tlinx.orgOn Sun Sep 01 15:16:33 2013, doughera wrote:
Going from tar and Configure, the problem I see now has to do with the I had been using Configure -da, but Merijn suggested: In answer to Merijn, RE, the suse-specific info provided:
which, unfortunately indicates that the suse-specific problem mentioned,
myconfig script attached.
Among others: lib/AnyDBM_File ............................................... # Complete log attached in makeperl-26754.log |
From @doughera88On Sun Sep 01 17:41:19 2013, LAWalsh wrote:
Ok. This is certainly different from the problem originally reported
Good. (On amd64, -Duse64bitall doesn't end up doing anything, but it's
Ok. That looks pretty normal.
Thank you. Now let's focus on the gdbm-related errors. It looks like 1. in the perl-5.18.0 directory, try simply running ./perl -Ilib -MGDBM_File -e 1; to make sure you can load the module. 2. If that works, try a simple test of the module, e.g. something #!./perl tie %check, 'GDBM_File', $filename, &GDBM_READER, 0644; 3. If either #1 or #2 fails, you can also check the integrity of your #include <stdio.h> int main (int argc, char **argv) My suspicion is that there's something wrong with your gdbm -- |
From perl-diddler@tlinx.orgOn Tue Sep 03 06:44:36 2013, doughera wrote:
I think that one might be a case where perl doesn't check or Ideally, at some point, it would be useful, in order to be able But that isn't what's going on here, at this point. ... shortcutting to the problem that the "C" program you provided *IF* gdbm was working correctly then this would be a case of using a 2nd problem) As the code assumes that blksize the size of a block on 2a) Somewhere it also makes the assumption that the optimal I/O size ========================== To protect against buggy gdbm (1.10 - 1.8.3 have the problem)
Yup -- and likely nearly 100% of others, as well, from 1.8.3-1.10, While I can probably, minimally, put in a hack on my machine, that won't This likely explains various problems I've had with Mail::Spamassassin It's made worse by the rpm that suse installs tries to put spamassassin So need to figure out where gdbmopen is called in perl and made sure any Hopefully that will let it build & pass testing. But maybe such a |
From @doughera88On Wed, Sep 04, 2013 at 09:57:46PM -0700, "Linda Walsh via RT" wrote:
Good detective work. Thank you.
The quick workaround for you is to edit line 26 in #define GDBM_BLOCKSIZE 0 /* gdbm defaults to stat blocksize */ and change the value of '0' to something that will work well for you. I agree that although the bug is in gdbm, perl ought to try to work around Meanwhile, would you be willing to report it to the gdbm maintainers? Thank you for the clear diagnosis. -- |
From @doughera88On Wed, Sep 04, 2013 at 09:57:46PM -0700, "Linda Walsh via RT" wrote:
I have filed a bug for the underlying gdbm issue as: As for the other build problems, I don't know what, specifically, you are More broadly, my general bias is that Configure ought to respect what ever I am going to close this ticket. If you have a specific build problem Thank you, -- |
|
@doughera88 - Status changed from 'open' to 'resolved' |
From perl-diddler@tlinx.orgOn Thu Sep 05 07:30:11 2013, doughera wrote:
Thanks. Unfortunately, that only gets around part of the problem. The other part involves "NDBM/ODBM" -- they both end up calling On the bright side, patching that 0 in the gdbm(compat) source to (I
Ok, let me rephrase -- Suppose someone thinks they want to build Compare that to to making the linux kernel. If I go into the Similarly, if values in PERL5OPTS (like -Mutf8::all, or -Mutf8 or It may be the case that some values (-M<special>) are To augment the default white-list, or, to skip extra validation of
Generally, I agree -- I'm just thinking of a sanity check to make As for the gdbm bug submission:... I sent the below, yesterday, but have -------- Original Message -------- In gdbmopen.c, ~ lines 235-242 we can see the dir size starting off Using a 12-data disk RAID of 64KB/segment, => 768K = 1 fullwidth When dirsize becomes > 768K, it will have jumped from 512K->1M. Following that at line 244, is a check: /* Check for correct block_size. */ But dir block size Cannot be equal to the desired block size, Either the prog needs to use dir_size/(sizeof(off_t)) to get dir The above was detected using the SuSE factory source rpm for what Also, a bit of oddness -- I know that several places use |
From @doughera88On Thu, Sep 05, 2013 at 04:56:34PM -0700, "Linda Walsh via RT" wrote:
Oh, right. You're using the gdbm emulations.
Fine. Or, you could just not include ndbm and odbm, unless you
Oh, ok. That's a different question. Your original problem report During the build, yes, some PERL5OPT settings can cause trouble. See -- |
From perl-diddler@tlinx.orgOn Thu Sep 05 18:44:19 2013, doughera wrote:
The initial build failed -- and I think that might have been due to
I'm saying that some of the "variability of symptoms" may have been Recently, I noted that the settings in the "GREP_OPTIONS" var can Perl is small enough that removing the old tree and and untarring a Thanks for the help... now have to figure out what to do with ndbm/odbm... Me, personally -- I don't care so much, but wanting it to be compat |
Migrated from rt.perl.org#119537 (status was 'resolved')
Searchable as RT119537$
The text was updated successfully, but these errors were encountered: