Configure misdetects strlcpy et al. with gcc -flto #12122
Comments
From @maukeCreated by @maukeHi, while trying to build perl-5.16.0 I ran into this problem: ... This is caused by Configure thinking I have malloc_size, strlcpy, etc. when I I was able to fix this problem with the following patch: Inline Patch--- perl-5.16.0-orig/Configure 2012-04-25 02:18:30.000000000 +0200
+++ perl-5.16.0/Configure 2012-05-15 08:11:20.000000000 +0200
@@ -7782,13 +7782,13 @@
if $contains $tlook $tf >/dev/null 2>&1; then
tval=true;
elif $test "$mistrustnm" = compile -o "$mistrustnm" = run; then
- echo "$extern_C void *$1$tdc; void *(*(p()))$tdc { return &$1; } int main() { if(p()) return(0); else return(1); }"> try.c;
+ echo "$extern_C void *$1$tdc; void *(*(p()))$tdc { return &$1; } int main() { if(p() && p() != (void *)main) return(0); else return(1); }"> try.c;
$cc -o try $optimize $ccflags $ldflags try.c >/dev/null 2>&1 $libs && tval=true;
$test "$mistrustnm" = run -a -x try && { $run ./try$_exe >/dev/null 2>&1 || tval=false; };
$rm_try;
fi;
else
- echo "$extern_C void *$1$tdc; void *(*(p()))$tdc { return &$1; } int main() { if(p()) return(0); else return(1); }"> try.c;
+ echo "$extern_C void *$1$tdc; void *(*(p()))$tdc { return &$1; } int main() { if(p() && p() != (void *)main) return(0); else return(1); }"> try.c;
$cc -o try $optimize $ccflags $ldflags try.c $libs >/dev/null 2>&1 && tval=true;
$rm_try;
fi;
Configure thinks I have these symbols because I'm building with -O2 -flto. My patch makes it actually check the address so gcc can't get rid of it Andy Dougherty reports that a workaround is to call ./Configure -Doptimize=-O2 [...] but then call make as make OPTIMIZE='-O2 -flto' Perl Info |
From @rjbsI would very much appreciate some opinions on the applicability of this change. |
From [Unknown Contact. See original ticket]I would very much appreciate some opinions on the applicability of this change. |
|
@rjbs - Status changed from 'new' to 'resolved' |
From @cpansproutOn Tue Jul 03 18:56:20 2012, rjbs wrote:
Did you mean to close it? -- Father Chrysostomos |
From [Unknown Contact. See original ticket]On Tue Jul 03 18:56:20 2012, rjbs wrote:
Did you mean to close it? -- Father Chrysostomos |
|
@cpansprout - Status changed from 'resolved' to 'open' |
From @nwc10On Tue, Jul 03, 2012 at 06:56:20PM -0700, Ricardo SIGNES via RT wrote:
It looks sane, but it is an area that caused great fun before. I think we push it to a smoke-me branch, but also try to ensure we test (ie I think that's the vendor C and C++ compilers on Solaris, HP-UX and AIX. Nicholas Clark |
From @maukeOn Wed Jul 04 03:06:14 2012, nicholas wrote:
Did anything happen in this area? My build is still failing with 5.16.3: /tmp/cc9ZpvJt.ltrans13.ltrans.o: In function `Perl_magic_set': |
From @maukeThis bug still exists in perl-5.18.0 Configure. |
From @rjbsI found this ticket in a list of things to review, sadly ignored for a long time. Lukas, are you still seeing this? It looks like this got delayed because of the proximity to release… twice. I'd like to get this closed now-ish, to avoid this happening AGAIN. -- |
From @shlomifHi all, On Wed Feb 26 16:02:01 2014, rjbs wrote:
For the record, I can still reproduce the build failure, and make and make test pass with the patch applied, after I did this: « I am on Mageia Linux x86-64 Cauldron (what will become Mageia 5) and I'm using gcc-4.8.2-5.mga5 . I can try testing with clang next to see if the fix broke anything.
Regards, -- Shlomi Fish |
From @shlomifOn Thu Mar 06 00:49:07 2014, shlomif wrote:
OK, tested the fix with this invocation: « After running them, "make" and "make test" were both successful - with some warnings on "make". Regards, — Shlomi Fish |
From @shlomifHi all, On Thu Mar 06 01:09:40 2014, shlomif wrote:
Tested now on a FreeBSD 9.2 VM with gcc46 (gcc-4.6). This command: sh Configure -de -Dprefix=$HOME/apps/perl/bleadperl -Dusedevel -Doptimize='-O2 -flto' -Dcc=gcc46 Succeeds there with and without the patch. make test succeeds without the patch, and with the patch I am getting this output with a failure in Benchmark (which I recall something that it could fail some time): [QUOTE] Stop in /usr/home/shlomif/Download/perl-from-git/perl. [/QUOTE] |
From @nwc10On Thu, Mar 06, 2014 at 08:38:21AM -0800, Shlomi Fish via RT wrote:
Cool. Do we have any non-gcc non-clang tests yet? Does anyone have a gcc 4.9 development build of gcc to test this? I seem to remember that Sun's compiler was a particular problem with this So demonstrating that Sun's compiler, IBM's compiler and HP's were happy Is this patch in a smoke-me branch yet? That gets some automated testing, and makes it a lot* easier to manually Nicholas Clark * "Yes, we're right with it. We can even handle context diffs" |
From @shlomifHi all, On Thu Mar 06 09:12:07 2014, nicholas wrote:
OK, per your interest, I have now built a gcc-4.9.x and without the patch and with this command: « I am getting a build failure in "make" later on (I'll post it shortly) without the patch. With this command-line: « everything builds but the following test failures are reported: [QUOTE] op/numconvert.t (Wstat: 0 Tests: 1444 Failed: 12) I'm on Mageia Linux x86-64 5/Cauldron . I built Regards, -- Shlomi Fish |
From @shlomifHi all, On Fri Mar 07 09:44:51 2014, shlomif wrote:
OK, here is the build failure and the command again: « « Regards, -- Shlomi Fish |
|
@Tux - Status changed from 'open' to 'pending release' |
From @khwilliamsonThanks for submitting this ticket The issue should be resolved with the release today of Perl v5.22. If you find that the problem persists, feel free to reopen this ticket -- |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
Migrated from rt.perl.org#113022 (status was 'resolved')
Searchable as RT113022$
The text was updated successfully, but these errors were encountered: