Bug 440974 - LD_PRELOAD variable causing problems when compiling Perl 5.10.0
LD_PRELOAD variable causing problems when compiling Perl 5.10.0
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: perl (Show other bugs)
rawhide
ppc64 Linux
low Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-04 15:02 EDT by Sérgio Durigan Júnior
Modified: 2008-04-08 14:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-08 14:53:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sérgio Durigan Júnior 2008-04-04 15:02:53 EDT
Description of problem:
======================

When I try to build the Perl's src.rpm (namely: perl-5.10.0-15.fc9.src.rpm) on a
Fedora 8 machine, I receive a lot of error messages saying:

ERROR: ld.so: object '/home/sergio/rpmbuild/BUILD/perl-5.10.0/libperl.so' from
LD_PRELOAD cannot be preloaded: ignored.

Ok, despite these messages Perl gets built successfuly and (apparently)
correctly. But after the build process, 5 tests fail in the "make test" step,
what causes 'rpmbuild' to exit with error. It is a very strong evidence that
this ld.so's error message is somehow avoiding the successful execution of some
tests.

After spending some time investigating this issue, I found that the guilty for
this is the patch named 'perl-5.8.8-rpath-make.patch'. After removing this patch
from the SPEC file, everything goes well and all tests pass. Unfortunately I
could not investigate in others platforms, but it seems that this patch is
useless (or problematic) now.


Version-Release number of selected component (if applicable)
============================================================
5.10.0


Steps to Reproduce
==================

1. Get the src.rpm file, install it;
2. On the top of you build directory, run "rpmbuild -bb SPECS/perl.spec";
3. Wait until 'miniperl' is built, then watch out the errors.


Additional info
===============

I'm using PPC64 arch here, and working on a patch for Perl to compile properly
on 64-bit archs. So, if you try to reproduce this bug on a 64-bit system you
*can* have some troubles. Unfortunately, as my patch isn't ready yet, I can't
send it. So, if you have some troubles, try add this parameter to you
"./Configure" line:

-Dcc='gcc -m64'
Comment 1 Tom "spot" Callaway 2008-04-04 15:38:12 EDT
This is almost certainly not the case, because we get this noise in rawhide
(Fedora 9), and it cleanly builds on ppc64.
Comment 3 Sérgio Durigan Júnior 2008-04-04 16:23:53 EDT
Hi Tom,

I can see that in your -Doptimize flag you have the '-m64' parameter, which
causes almost everything to be compiled with this parameter too. As an example,
let's take the command below:

`sh  cflags "optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc'"
generate_uudmap.o` -fPIC generate_uudmap.c
	  CCCMD =  gcc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE -DDEBUGGING
-fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm  -std=c89 -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mminimal-toc  -Wall -ansi -pedantic -W -Wextra
-Wdeclaration-after-statement -Wendif-labels -Wc++-compat -DPERL_GCC_PEDANTIC 

As you can see, 'generate_uudpmap.o' is a 64-bit object file. But a few lines
after this, we can see:

gcc -o generate_uudmap  generate_uudmap.o -lresolv -lnsl -ldl -lm -lcrypt -lutil
-lpthread -lc
./generate_uudmap >uudmap.h

Well, now there isn't a '-m64' flag, but the compilation still succeed. This is
exactly the problem which I described in the "Additional info" session, and I
have a gcc that generates natively 32-bit binaries. So, if I'm not wrong in my
suppositions you're using a gcc that generates natively 64-bit binaries, right?
For that problem, I'm finishing a patch to Perl's build system that fixes this.

Maybe this is the issue then. I cannot reproduce your successful compilation
here because I'm using the gcc shipped with Fedora 8 for PPC64. Do you know if
there's a plan to include a gcc that generates natively 64-bit binaries on Fedora 9?

P.S.: If you want, I can upload my build.log here. It's up to you :-).
Comment 4 Tom "spot" Callaway 2008-04-04 16:51:04 EDT
Yes, the Fedora ppc64 gcc is a native 64bit compiler, so it defaults to -m64.

This should be the case in Fedora 8 as well, so I'm not sure why yours does not.
Perhaps you have both ppc and ppc64, and ppc got written to disk second?

This is why Fedora packages builds are done in a clean chroot, populated only
with packages specifically for the architecture target (in this case, ppc64).

I've hit similar compiler issues in the past when building for sparc64 with a
sparc gcc (it can build for both -m32 and -m64, but defaults to -m32), and they
were also resolved by using a sparc64 targeted compiler that defaulted to -m64.
Comment 5 Sérgio Durigan Júnior 2008-04-08 10:36:10 EDT
Thanks for the information, Tom. Well, the thing is that I have Fedora 8 for PPC
installed on this machine (since there's no Fedora 8 for PPC64), and I haven't
done anything special in this installation, which means that every package here
is the default that comes with FC 8. I'd like to know if you have done some kind
of "different installation" in order to get a native 64-bit gcc.
Comment 6 Tom "spot" Callaway 2008-04-08 10:53:20 EDT
There is no ppc64 spin, but all of the packages are built for ppc64:

http://download.fedora.redhat.com/pub/fedora/linux/releases/8/Everything/ppc64/os/Packages/



Note You need to log in before you can comment on or make changes to this bug.