Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Perl: porters

[PATCH] Re: Compiling perl (5.10.x) with gcc <= 3.2.3

 

 

Perl porters RSS feed   Index | Next | Previous | View Threaded


doughera at lafayette

May 16, 2008, 10:59 AM

Post #1 of 3 (70 views)
Permalink
[PATCH] Re: Compiling perl (5.10.x) with gcc <= 3.2.3

> > On Fri, 16 May 2008, Bram wrote:
> >
> > > With gcc <= 3.2.3 I get:
> > >
> > > make test
> > > t/base/rs.....................................................Can't
> > > load '../lib/auto/PerlIO/scalar/scalar.so' for module PerlIO::scalar:
> > > libgcc_s.so.1: cannot open shared object file: No such file or
> > > directory at ../lib/XSLoader.pm line 64.
> > > at ../lib/PerlIO/scalar.pm line 4
> >
> > > I have the file libgcc_s.so.1 in /opt/gcc/3.2.3/lib/libgcc_s.so.1
> > > (gcc was compiled with prefix=/opt/gcc/3.2.3)
> > >
> > > Setting LD_LIBRARY_PATH to /opt/gcc/3.2.3/lib/ and running make test
> > > results in 'All tests successful.'.


I wrote:

> > I've seen a similar problem with the -fstack-protector stuff in bleadperl
> > (see [perl #54120] for a patch).
> >
> > To see if this is our fault or gcc's, can you try the following in a
> > succeeding and in a failing configuration:
> >
> > grep 'ld.*flags' config.sh
>
> compiled with gcc-3.2.3: (needs LD_LIBRARY_PATH)
> lddlflags='-shared -O2 -L/usr/local/lib'
> ldflags=' -L/usr/local/lib'
> ldflags_uselargefiles=''
>
> compiled with gcc-3.3.1: (doesn't need LD_LIBRARY_PATH)
> lddlflags='-shared -O2 -L/usr/local/lib'
> ldflags=' -L/usr/local/lib'
> ldflags_uselargefiles=''

Ok, no change there. I think it's fair to say this is gcc-3.2.3's fault.
Where gcc keeps libgcc_s.so.1 is an internal implementation detail that
the end user shouldn't have to know.

Further, since gcc-3.2.3 is sufficiently old that newer versions are
probably available (3.2.3 was released in April 2003, while 3.3.0 was
released in May 2003) it's probably not too important for us to
automatically work around it.

I'm not sure if we should do anything. Perhaps add a note to INSTALL?

--- perl-current/INSTALL 2007-12-19 08:50:44.000000000 -0500
+++ perl-andy/INSTALL 2008-05-16 13:58:21.000000000 -0400
@@ -1886,6 +1886,13 @@
tries to exercise the regular expression subsystem quite thoroughly,
and may well be far more demanding than your normal usage.

+=item libgcc_s.so.1: cannot open shared object file
+
+This message has been reported on gcc-3.2.3 and earlier installed with
+a non-standard prefix. Setting the LD_LIBRARY_PATH environment variable
+(or equivalent) to include gcc's lib/ directory with the libgcc_s.so.1
+shared library should fix the problem.
+
=item Failures from lib/File/Temp/t/security saying "system possibly insecure"

First, such warnings are not necessarily serious or indicative of a

--
Andy Dougherty doughera[at]lafayette.edu


h.m.brand at xs4all

May 17, 2008, 6:49 AM

Post #2 of 3 (57 views)
Permalink
Re: [PATCH] Re: Compiling perl (5.10.x) with gcc <= 3.2.3 [In reply to]

On Fri, 16 May 2008 13:59:41 -0400 (EDT), Andy Dougherty
<doughera[at]lafayette.edu> wrote:

> Ok, no change there. I think it's fair to say this is gcc-3.2.3's fault.
> Where gcc keeps libgcc_s.so.1 is an internal implementation detail that
> the end user shouldn't have to know.
>
> Further, since gcc-3.2.3 is sufficiently old that newer versions are
> probably available (3.2.3 was released in April 2003, while 3.3.0 was
> released in May 2003) it's probably not too important for us to
> automatically work around it.
>
> I'm not sure if we should do anything. Perhaps add a note to INSTALL?

Thanks applied as change #33841

I first though it better fit README.linux, but I guess it can happen on
every OS

> --- perl-current/INSTALL 2007-12-19 08:50:44.000000000 -0500
> +++ perl-andy/INSTALL 2008-05-16 13:58:21.000000000 -0400
> @@ -1886,6 +1886,13 @@
> tries to exercise the regular expression subsystem quite thoroughly,
> and may well be far more demanding than your normal usage.
>
> +=item libgcc_s.so.1: cannot open shared object file
> +
> +This message has been reported on gcc-3.2.3 and earlier installed with
> +a non-standard prefix. Setting the LD_LIBRARY_PATH environment variable
> +(or equivalent) to include gcc's lib/ directory with the libgcc_s.so.1
> +shared library should fix the problem.
> +
> =item Failures from lib/File/Temp/t/security saying "system possibly insecure"
>
> First, such warnings are not necessarily serious or indicative of a
>


--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/


p5p at perl

May 17, 2008, 9:41 AM

Post #3 of 3 (54 views)
Permalink
Re: [PATCH] Re: Compiling perl (5.10.x) with gcc <= 3.2.3 [In reply to]

Quoting Andy Dougherty <doughera[at]lafayette.edu>:

>> > On Fri, 16 May 2008, Bram wrote:
>> >
>> > > With gcc <= 3.2.3 I get:
>> > >
>> > > make test
>> > > t/base/rs.....................................................Can't
>> > > load '../lib/auto/PerlIO/scalar/scalar.so' for module PerlIO::scalar:
>> > > libgcc_s.so.1: cannot open shared object file: No such file or
>> > > directory at ../lib/XSLoader.pm line 64.
>> > > at ../lib/PerlIO/scalar.pm line 4
>> >
>> > > I have the file libgcc_s.so.1 in /opt/gcc/3.2.3/lib/libgcc_s.so.1
>> > > (gcc was compiled with prefix=/opt/gcc/3.2.3)
>> > >
>> > > Setting LD_LIBRARY_PATH to /opt/gcc/3.2.3/lib/ and running make test
>> > > results in 'All tests successful.'.
>
>
> I wrote:
>
>> > I've seen a similar problem with the -fstack-protector stuff in bleadperl
>> > (see [perl #54120] for a patch).
>> >
>> > To see if this is our fault or gcc's, can you try the following in a
>> > succeeding and in a failing configuration:
>> >
>> > grep 'ld.*flags' config.sh
>>
>> compiled with gcc-3.2.3: (needs LD_LIBRARY_PATH)
>> lddlflags='-shared -O2 -L/usr/local/lib'
>> ldflags=' -L/usr/local/lib'
>> ldflags_uselargefiles=''
>>
>> compiled with gcc-3.3.1: (doesn't need LD_LIBRARY_PATH)
>> lddlflags='-shared -O2 -L/usr/local/lib'
>> ldflags=' -L/usr/local/lib'
>> ldflags_uselargefiles=''
>
> Ok, no change there. I think it's fair to say this is gcc-3.2.3's fault.
> Where gcc keeps libgcc_s.so.1 is an internal implementation detail that
> the end user shouldn't have to know.
>
> Further, since gcc-3.2.3 is sufficiently old that newer versions are
> probably available (3.2.3 was released in April 2003, while 3.3.0 was
> released in May 2003) it's probably not too important for us to
> automatically work around it.
>
> I'm not sure if we should do anything. Perhaps add a note to INSTALL?

Looking further into this (because g++ 4.3.0 is not doing what it
should either - or atleast on one machine, another one works fine):

http://gcc.gnu.org/faq.html#rpath

This works for 3.2.3 (and I assume earlier - not yet tested):

export LD_RUN_PATH=/opt/gcc/3.2.3/lib
./Configure -des -Dusedevel=y -Dcc=/opt/gcc/3.2.3/gcc
make
export LD_RUN_PATH=""
make test

Perl porters RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.