Skip Menu |
 

This queue is for tickets about the Compress-Raw-Zlib CPAN distribution.

Report information
The Basics
Id: 88936
Status: resolved
Priority: 0/
Queue: Compress-Raw-Zlib

People
Owner: Nobody in particular
Requestors: RURBAN [...] cpan.org
Cc: perl5-porters [...] perl.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: 2.062
Fixed in: 2.065

Attachments
0001-fix-88936-out-of-memory-with-g3-since-2.062.patch
0004-Allow-to-compile-under-gdb3-under-gcc.patch



CC: perl5-porters [...] perl.org
Subject: gcc -g3: final link failed: Memory exhausted
With the new Compress-Raw-Zlib-2.062 version in blead compilation with gcc -g3 (4.7 and 4.8) fails to link with cc -shared -g3 -L/usr/local/lib -fstack-protector Zlib.o adler32.o crc32.o infback.o inflate.o uncompr.o compress.o deflate.o inffast.o inftrees.o trees.o zutil.o -o ../../lib/auto/Compress/Raw/Zlib/Zlib.so \ /usr/bin/ld: final link failed: Memory exhausted I have to clean all *.o and recompile with -g to be able to link this. -g3 stores macros in dwarf. Maybe there's a new recursive macro. 2.061 worked fine. A workaround until the real problem is being found is to add a hints file, which checks for -g3 in OPTIMIZE and replaces it with -g Inspecting core ef379d05f8358 reveils nothing obvious to me, so maybe it's a recent core change, not the 2.062 change. The last successful blead build with -g3 was at Sep 16, with a2553af6e5f1db5aac7e0bb23db887f37101de35 With git log -p a2553af6e5f1db5aac7e0bb23db887f37101de35...c6ba15252667d61624481a75c7b61acee4e89cb3 -- ..*.h nothing springs into my eye neither, but there were a lot of perl.h changes. -- Reini Urban
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.9k
Found a fix: -g3 -fdebug-types-section on gcc 4.7.3 and higher fixes the 'final link failed: Memory exhausted' problem with -g3. It cannot be memory, since the sum of all *.o is lower than 1MB and I have 16MB RAM. So it's apparently a new gcc dwarf linking problem, with the introduction of the -fdebug-types-section switch. http://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html: "When using DWARF Version 4 or higher, type DIEs can be put into their own .debug_types section instead of making them part of the .debug_info section. It is more efficient to put them in a separate comdat sections since the linker can then remove duplicates. But not all DWARF consumers support .debug_types sections yet and on some objects .debug_types produces larger instead of smaller debugging information." On Tue Sep 24 11:31:02 2013, RURBAN wrote: Show quoted text
> With the new Compress-Raw-Zlib-2.062 version in blead > compilation with gcc -g3 (4.7 and 4.8) fails to link with > > cc -shared -g3 -L/usr/local/lib -fstack-protector Zlib.o adler32.o > crc32.o infback.o inflate.o uncompr.o compress.o deflate.o inffast.o > inftrees.o trees.o zutil.o -o > ../../lib/auto/Compress/Raw/Zlib/Zlib.so \ > /usr/bin/ld: final link failed: Memory exhausted > > I have to clean all *.o and recompile with -g to be able to link this. > -g3 stores macros in dwarf. > > Maybe there's a new recursive macro. 2.061 worked fine. > A workaround until the real problem is being found is to add a hints > file, which checks for -g3 in OPTIMIZE and replaces it with -g > > Inspecting core ef379d05f8358 reveils nothing obvious to me, so maybe > it's a recent core change, not the 2.062 change. > The last successful blead build with -g3 was at Sep 16, with > a2553af6e5f1db5aac7e0bb23db887f37101de35 > > With git log -p > a2553af6e5f1db5aac7e0bb23db887f37101de35...c6ba15252667d61624481a75c7b61acee4e89cb3 > -- ..*.h > nothing springs into my eye neither, but there were a lot of perl.h > changes.
-- Reini Urban
Download (untitled) / with headers
text/plain 404b
On Tue Sep 24 12:31:34 2013, RURBAN wrote: Show quoted text
> Found a fix: > > -g3 -fdebug-types-section > on gcc 4.7.3 and higher fixes the 'final link failed: Memory > exhausted' problem with -g3.
nope, spoke too early. This didn't help either. only '-g3 -gstabs -fdebug-types-section' helps if you want -g level 3 (macros). This slows down run-time, so it should go into the docs or a hints file if reproducable.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 348b
Attached patch changes -g3 to -g for this 2.062 release. It's only a cc problem, not ld. I've checked older perl debugging releases with optimize containing -g3 and they failed with the same problem, so it's definitely only a problem with a MACRO with the update to 2.062. Patch also at https://github.com/rurban/Compress-Raw-Zlib -- Reini Urban
Subject: 0001-fix-88936-out-of-memory-with-g3-since-2.062.patch
From 279cb26adc135669eb9f525bccee92aede997e3a Mon Sep 17 00:00:00 2001 From: Reini Urban <rurban@cpanel.net> Date: Fri, 27 Sep 2013 12:13:35 -0500 Subject: [PATCH] fix [88936] out of memory with -g3 since 2.062 change -g3 to -g with gcc --- Makefile.PL | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Makefile.PL b/Makefile.PL index d8c060d..aba7abc 100644 --- a/Makefile.PL +++ b/Makefile.PL @@ -6,6 +6,7 @@ require 5.006 ; use private::MakeUtil; use ExtUtils::MakeMaker 5.16 ; use ExtUtils::Install (); # only needed to check for version +use Config; my $ZLIB_LIB ; my $ZLIB_INCLUDE ; @@ -14,6 +15,10 @@ my $OLD_ZLIB = '' ; my $WALL = '' ; my $GZIP_OS_CODE = -1 ; my $USE_PPPORT_H = ($ENV{PERL_CORE}) ? '' : '-DUSE_PPPORT_H'; +my $OPTIMIZE = $Config{'optimize'}; +if ($Config{'gccversion'} and $OPTIMIZE =~ /-g3/) { + $OPTIMIZE =~ s/-g3/-g/; # [88936] out of memory with -g3 since 2.062 +} #$WALL = ' -pedantic ' if $Config{'cc'} =~ /gcc/ ; #$WALL = ' -Wall -Wno-comment ' if $Config{'cc'} =~ /gcc/ ; @@ -81,7 +86,8 @@ WriteMakefile( ? zlib_files($ZLIB_LIB) : (LIBS => [ "-L$ZLIB_LIB -lz " ]) ), - + OPTIMIZE => $OPTIMIZE, + INSTALLDIRS => ($] >= 5.009 && $] < 5.011 ? 'perl' : 'site'), META_MERGE => { -- 1.8.4.rc3
Download (untitled) / with headers
text/plain 625b
Hey Reini, not sure how 2.061 works while 2.062 doesn't. The only change made that impacts the code was to Makefile.PL to tighten up the code that allows a prebuilt zlib library to be used, rather than the one I ship. Do you make use of the env variables ZLIB_INCLUDE, ZLIB_LIBRARY or BUILD_ZLIB? I don't mind adding this change if that's the only option. Would be good to get to the bottom of the issue & fix that, but I don't have gcc 4.7/8. I assume the issue is caused by an interaction between Perl C macros & the ones that zlib uses. Sorry for not getting back to you sooner on this, but $WORK has been hectic. Paul
From: rurban [...] x-ray.at
Download (untitled) / with headers
text/plain 791b
Hey Paul, On Mon Oct 21 04:35:50 2013, PMQS wrote: Show quoted text
> not sure how 2.061 works while 2.062 doesn't. The only change made > that impacts the code was to Makefile.PL to tighten up the code that > allows a prebuilt zlib library to be used, rather than the one I ship. > Do you make use of the env variables ZLIB_INCLUDE, ZLIB_LIBRARY or > BUILD_ZLIB?
Nope. zlib is provided by debian. Show quoted text
> I don't mind adding this change if that's the only option. Would be > good to get to the bottom of the issue & fix that, but I don't have > gcc 4.7/8. I assume the issue is caused by an interaction between Perl > C macros & the ones that zlib uses.
I'm pretty sure it's a new recursive perl macro which caused this problem only here, but I haven't found it yet. This is the only way to fix it for now.
Download (untitled) / with headers
text/plain 280b
On Wed Oct 23 11:37:22 2013, rurban@x-ray.at wrote: ... Show quoted text
> > I'm pretty sure it's a new recursive perl macro which caused this > problem only here, > but I haven't found it yet. > This is the only way to fix it for now.
OK. I've added your change to my development copy. Paul
From: rurban [...] x-ray.at
Download (untitled) / with headers
text/plain 2.6k
Dave Mitchell found the gcc problem with infback.c, so it's no a perl CORE problem Show quoted text
> Nope, it appears to be a gcc bug. > First, it's reproducible with just linking infback.o, which doesn't rely > on perl src; and second, I've reduced it to the following minimal case: > > $ cc -c -g3 -fstack-protector -fPIC foo.c > $ cc -shared -g3 foo.o -o /tmp/foo.so > /usr/bin/ld: final link failed: Memory exhausted > collect2: error: ld returned 1 exit status > foo.c: > > #define FOO1 > #define FOO2 > #define FOO3 > #define FOO4 > #define FOO5 > #define FOO6 > #define FOO7 > #define FOO8 > #define FOO9 > #define FOO10 > #define FOO11 > #define FOO12 > #define FOO13 > #define FOO14 > #define FOO15 > #define FOO16 > #define FOO17 > #define FOO18 > #define FOO19 > #define FOO20 > #define FOO21 > #define FOO22 > #define FOO23 > #define FOO24 > #define FOO25 > #define FOO26 > #define FOO27 > #define FOO28 > #define BAR1 > #define BAR2 > #define BAR3 > #define BAR4 > #define BAR5 > #define BAR6 > #define BAR7 > #define BAR8 > #define BAR9 > #define BAR10 > #define BAR11 > #define BAR12 > #define BAR13 > #define BAR14 > #define BAR15 > #define BAR16 > #define BAR17 > #define BAR18 > #define BAR19 > #define BAR20 > #define BAR21 > #define BAR22 > #define BAR23 > #define BAR24 > #define BAR25 > #define BAR26 > #define BAR27 > #define BAR28 > #define BAR29 > #define BAR30 > #define BAR31 > #define BAR32 > #define BAR33 > #define BAR34 > #define BAR35 > #define BAR36 > #define BAR37 > #define BAR38 > #define BAR39 > #define BAR40 > #define BAR41 > #define BAR42 > #define BAR43 > #define BAR44 > #define BAR45 > #define BAR46 > #define BAR47 > #define BAR48 > #define BAR49 > #define BAR50 > #define BAR51 > #define BAR52 > #define BAR53 > #define BAR54 > #define BAR55 > #define BAR56 > #define BAR57 > #define BAR58 > #define BAR59 > #define BAR60 > #define BAR61 > #define ZLIB_VER_SUBREVISION 0 > > typedef char chr1; > typedef chr1 chr2; > typedef int int2; > typedef int int1; > typedef void *voidpf; > typedef void (*funcp)(); > > struct struct4 {int i;}; > > typedef struct struct3 { > unsigned int v2; > int v3; > long v6; > char v7; > int v12; > int v13; > int1 v14; > int2 v5; > chr2 v4; > chr2 v1; > struct struct4 *v8; > funcp v9; > funcp v10; > voidpf v11; > } struct2; > > typedef struct2 *type2; > > typedef short foo1; > > typedef enum { > E1, E2, E3, E4, E5, E6, E7, E8, E9, E10, E11, E12, E13, E14, E15, > } enum1; > > struct struct1 { > enum1 mode; > }; > > int f1(type2 t2, int i1, int i2, int i3, int i4) { > struct struct1 *s1; > } > >
From: fraserbn [...] gmail.com
Download (untitled) / with headers
text/plain 601b
On Wed Oct 23 17:57:24 2013, PMQS wrote: Show quoted text
> On Wed Oct 23 11:37:22 2013, rurban@x-ray.at wrote: > ... >
> > > > I'm pretty sure it's a new recursive perl macro which caused this > > problem only here, > > but I haven't found it yet. > > This is the only way to fix it for now.
> > OK. I've added your change to my development copy. > > Paul >
Howdy, It looks like this issue is still showing it's ugly head around. In particular, it still affects perls compiled with either -O3 or greater, or with -ggdb3. So I think that Makefile.PL needs to change those to -O2 and -ggdb2. Thanks in advance!
From: khw [...] cpan.org
Download (untitled) / with headers
text/plain 853b
On Sun Feb 02 07:59:09 2014, Hugmeir wrote: Show quoted text
> On Wed Oct 23 17:57:24 2013, PMQS wrote:
> > On Wed Oct 23 11:37:22 2013, rurban@x-ray.at wrote: > > ... > >
> > > > > > I'm pretty sure it's a new recursive perl macro which caused this > > > problem only here, > > > but I haven't found it yet. > > > This is the only way to fix it for now.
> > > > OK. I've added your change to my development copy. > > > > Paul > >
> > Howdy, > > It looks like this issue is still showing it's ugly head around. In > particular, it still affects perls compiled with either -O3 or > greater, or with -ggdb3. So I think that Makefile.PL needs to change > those to -O2 and -ggdb2. > > Thanks in advance!
Attached is a patch that does this. It also adds a /g to the substitution operator, as it is legal to specify the option multiple times, and each should be changed.
Subject: 0004-Allow-to-compile-under-gdb3-under-gcc.patch
From 99d67d6dcd303a689a57ce4f01f5f13d9a6a589c Mon Sep 17 00:00:00 2001 From: Karl Williamson <public@khwilliamson.com> Date: Sun, 2 Feb 2014 08:51:09 -0700 Subject: [PATCH 4/4] Allow to compile under -gdb3 under gcc --- cpan/Compress-Raw-Zlib/Makefile.PL | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/cpan/Compress-Raw-Zlib/Makefile.PL b/cpan/Compress-Raw-Zlib/Makefile.PL index aba7abc..015c1d9 100644 --- a/cpan/Compress-Raw-Zlib/Makefile.PL +++ b/cpan/Compress-Raw-Zlib/Makefile.PL @@ -16,8 +16,8 @@ my $WALL = '' ; my $GZIP_OS_CODE = -1 ; my $USE_PPPORT_H = ($ENV{PERL_CORE}) ? '' : '-DUSE_PPPORT_H'; my $OPTIMIZE = $Config{'optimize'}; -if ($Config{'gccversion'} and $OPTIMIZE =~ /-g3/) { - $OPTIMIZE =~ s/-g3/-g/; # [88936] out of memory with -g3 since 2.062 +if ($Config{'gccversion'} and $OPTIMIZE =~ /-g (gdb)? 3/x) { + $OPTIMIZE =~ s/-g(gdb)?3/-g/g; # [88936] out of memory with -g3 since 2.062 } #$WALL = ' -pedantic ' if $Config{'cc'} =~ /gcc/ ; -- 1.8.3.2
Thanks - patch applied. Paul


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.