Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not OK: perl v5.7.3 +DEVEL16824 on i686-linux-64int 2.4.18 (UNINSTALLED) #5489

Closed
p5pRT opened this issue May 28, 2002 · 13 comments
Closed

Not OK: perl v5.7.3 +DEVEL16824 on i686-linux-64int 2.4.18 (UNINSTALLED) #5489

p5pRT opened this issue May 28, 2002 · 13 comments

Comments

@p5pRT
Copy link

p5pRT commented May 28, 2002

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

Searchable as RT9402$

@p5pRT
Copy link
Author

p5pRT commented May 28, 2002

From @nwc10

../perl -Ilib t/op/int.t
1..14
ok 1
ok 2
ok 3
ok 4
ok 5
not ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14

This is the same failure that Kay Röpke sees on his smoke
He's using glibc 2.2.5 (on Debian testing).
This box is debian, with glibc 2.2.5
[But it's a different gcc version, and is a Cyrix/II 266.

I don't know what the problem is (yet)
Has anyone else seen this failure? I think you need to be building with long
long IVs.

Nicholas Clark

Perl Info

Flags:
    category=install
    severity=none

Site configuration information for perl v5.7.3:

Configured by nick at Tue May 28 16:14:31 BST 2002.

Summary of my perl5 (revision 5.0 version 7 subversion 3 patch 16827) configuration:
  Platform:
    osname=linux, osvers=2.4.18, archname=i686-linux-64int
    uname='linux penfold 2.4.18 #1 mon apr 15 11:47:12 bst 2002 i686 unknown '
    config_args='-de -Dcc=ccache gcc -Dld=gcc -Dusedevel -Ubincompat5005 -Doptimize=-Os -Uinstallusrbinperl -Dcf_email=nick@ccl4.org -Dperladmin=nick@ccl4.org -Dinc_version_list=  -Dinc_version_list_init=0 -Dinstallman1dir=none -Dinstallman3dir=none -Duse64bitint'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=define use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='ccache gcc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-Os',
    cppflags='-fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.4 20011002 (Debian prerelease)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -ldb -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    DEVEL16824


@INC for perl v5.7.3:
    lib
    /usr/local/lib/perl5/5.7.3/i686-linux-64int
    /usr/local/lib/perl5/5.7.3
    /usr/local/lib/perl5/site_perl/5.7.3/i686-linux-64int
    /usr/local/lib/perl5/site_perl/5.7.3
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.7.3:
    HOME=/home/nick
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games
    PERL_BADLANG (unset)
    SHELL=/bin/sh


@p5pRT
Copy link
Author

p5pRT commented May 28, 2002

From [Unknown Contact. See original ticket]

On Tue, 28 May 2002 21​:07 +0100, Nicholas Clark wrote​:

This is a build failure report for perl from nick@​ccl4.org,
generated with the help of perlbug 1.33 running under perl v5.7.3.

-----------------------------------------------------------------
[Please enter your report here]

../perl -Ilib t/op/int.t
1..14
ok 1
ok 2
ok 3
ok 4
ok 5
not ok 6
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12
ok 13
ok 14

This is the same failure that Kay Röpke sees on his smoke
He's using glibc 2.2.5 (on Debian testing).
This box is debian, with glibc 2.2.5
[But it's a different gcc version, and is a Cyrix/II 266.

I don't know what the problem is (yet)
Has anyone else seen this failure? I think you need to be building with long
long IVs.

I saw the same problem this morning and it is a glibc bug​:
http​://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65612

--
Radu Greab

@p5pRT
Copy link
Author

p5pRT commented May 28, 2002

From @nwc10

On Tue, May 28, 2002 at 11​:17​:55PM +0300, Radu Greab wrote​:

On Tue, 28 May 2002 21​:07 +0100, Nicholas Clark wrote​:

This box is debian, with glibc 2.2.5
[But it's a different gcc version, and is a Cyrix/II 266.

I don't know what the problem is (yet)
Has anyone else seen this failure? I think you need to be building with long
long IVs.

I saw the same problem this morning and it is a glibc bug​:
http​://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65612

Thanks. I'm not going mad. And I don't now have to track it down.
Is there an obvious way to

1​: Detect this at Configure time?
2​: Work round it?

Nicholas Clark
--
Even better than the real thing​: http​://nms-cgi.sourceforge.net/

@p5pRT
Copy link
Author

p5pRT commented May 28, 2002

From [Unknown Contact. See original ticket]

On Tue, 28 May 2002 22​:22 +0100, Nicholas Clark wrote​:

On Tue, May 28, 2002 at 11​:17​:55PM +0300, Radu Greab wrote​:

On Tue, 28 May 2002 21​:07 +0100, Nicholas Clark wrote​:

This box is debian, with glibc 2.2.5
[But it's a different gcc version, and is a Cyrix/II 266.

I don't know what the problem is (yet)
Has anyone else seen this failure? I think you need to be building with long
long IVs.

I saw the same problem this morning and it is a glibc bug​:
http​://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=65612

Thanks. I'm not going mad. And I don't now have to track it down.
Is there an obvious way to

2​: Work round it?

Yes, we can work round it by making sure that the second operand of
modulo is a positive integer​:

Inline Patch
--- pp.c~	Tue May 21 19:01:32 2002
+++ pp.c	Wed May 29 00:57:54 2002
@@ -2422,6 +2422,10 @@
       dPOPTOPiirl;
       if (!right)
 	DIE(aTHX_ "Illegal modulus zero");
+#ifdef HAS_MODDI3_NEG_BUG
+      if (right < 0)
+	right = -right;
+#endif
       SETi( left % right );
       RETURN;
     }

 > 1: Detect this at Configure time?

Yes, but my skills are not up to the task of modifying the required headers to add HAS\_MODDI3\_NEG\_BUG and to the task of updating Configure\.

Could someone skilled at this do the following Configure test​: if we
are using glibc 2.2.5 and use64bitint or use64bitall or usemorebits
was requested and the following test program prints "__moddi3 buggy",
then define HAS_MODDI3_NEG_BUG in order to enable the workaround.

Test code​:

#include <stdio.h>

int main() {
  long long int left = 3;
  long long int right = -10;
  if (left % right == -3)
  printf("_moddi3 is buggy\n");
}

Thanks,
Radu Greab

@p5pRT
Copy link
Author

p5pRT commented May 28, 2002

From @jhi

Yes, but my skills are not up to the task of modifying the required
headers to add HAS_MODDI3_NEG_BUG and to the task of updating
Configure.

Could someone skilled at this do the following Configure test​: if we
are using glibc 2.2.5 and use64bitint or use64bitall or usemorebits
was requested and the following test program prints "__moddi3 buggy",
then define HAS_MODDI3_NEG_BUG in order to enable the workaround.

At this point in time I prefer any combination of the below​:

(1) pod/perldelta.pod entry warning about glibc 2.2.5
(2) hints/linux.sh warning about the matter (yes, glibc
  is not linux only, I know)

But I do not feel like twiddling with Configure now, especially
not for a single broken function.

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

@p5pRT
Copy link
Author

p5pRT commented May 29, 2002

From @nwc10

On Wed, May 29, 2002 at 02​:17​:00AM +0300, Jarkko Hietaniemi wrote​:

At this point in time I prefer any combination of the below​:

(1) pod/perldelta.pod entry warning about glibc 2.2.5
(2) hints/linux.sh warning about the matter (yes, glibc
is not linux only, I know)

But I do not feel like twiddling with Configure now, especially
not for a single broken function.

I was also wondering if we're even doing the right thing with all our games
at attempting to work round bugs in shared libraries. All we're doing is
placating the testsuite on the machine that builds perl at the time of
building perl. It's quite possible that that perl will be binary packaged
on a machine that doesn't have the bug, and shipped to a machine with
the buggy library, so we ought to have the work around in for that case
Or that the machine doesn't have the library at build time, but is upgraded
to the buggy version, at which point we the workaround would be nice.

Equally well, any machine with a current buggy library would like the
performance gain of not having the workaround once the bug is fixed and
its library is upgraded.

This is partly a question about why we work around broken things that are
likely to get fixed, but mainly should we have option 3​:

(3) TODO test in t/op/int.t if we have a way of knowing the libc version.
  Or a some sort of warning there, if the test fails in a known way and
  $^O is linux (or whatever $^O is on the Hurd or anything else using
  glibc)

Nicholas Clark

@p5pRT
Copy link
Author

p5pRT commented May 30, 2002

From @jhi

On Wed, May 29, 2002 at 09​:38​:58AM +0100, Nicholas Clark wrote​:

On Wed, May 29, 2002 at 02​:17​:00AM +0300, Jarkko Hietaniemi wrote​:

At this point in time I prefer any combination of the below​:

(1) pod/perldelta.pod entry warning about glibc 2.2.5

This is what I did now.

(2) hints/linux.sh warning about the matter (yes, glibc
is not linux only, I know)

But I do not feel like twiddling with Configure now, especially
not for a single broken function.

I was also wondering if we're even doing the right thing with all our games
at attempting to work round bugs in shared libraries. All we're doing is
placating the testsuite on the machine that builds perl at the time of
building perl. It's quite possible that that perl will be binary packaged
on a machine that doesn't have the bug, and shipped to a machine with
the buggy library, so we ought to have the work around in for that case
Or that the machine doesn't have the library at build time, but is upgraded
to the buggy version, at which point we the workaround would be nice.

Equally well, any machine with a current buggy library would like the
performance gain of not having the workaround once the bug is fixed and
its library is upgraded.

This is partly a question about why we work around broken things that are
likely to get fixed, but mainly should we have option 3​:

(3) TODO test in t/op/int.t if we have a way of knowing the libc version.
Or a some sort of warning there, if the test fails in a known way and
$^O is linux (or whatever $^O is on the Hurd or anything else using
glibc)

Nicholas Clark

--
$jhi++; # http​://www.iki.fi/jhi/
  # There is this special biologist word we use for 'stable'.
  # It is 'dead'. -- Jack Cohen

@p5pRT
Copy link
Author

p5pRT commented Nov 30, 2002

From @jhi

I think this got resolved, so I'm marking the problem ticket as such.

@p5pRT
Copy link
Author

p5pRT commented Nov 30, 2002

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

@p5pRT
Copy link
Author

p5pRT commented Jan 16, 2003

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

@p5pRT
Copy link
Author

p5pRT commented Jan 16, 2003

From @nwc10

It's still live, and a couple of smokers are now seeing it. I think the
patch never got applied because no Configure test was made for it.

@p5pRT
Copy link
Author

p5pRT commented Mar 2, 2003

From @rspier

Finally fixed by jhi in the thread starting with....

Date​: Sat, 1 Mar 2003 22​:57​:51 +0200
From​: Jarkko Hietaniemi <jhi@​iki.fi>
To​: perl5-porters@​perl.org
Subject​: [PATCH] glibc _moddi3
Message-ID​: <20030301205751.GB7547@​kosh.hut.fi>

Change 18797.

@p5pRT p5pRT closed this as completed Mar 2, 2003
@p5pRT
Copy link
Author

p5pRT commented Mar 2, 2003

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant