Bug 133680

Summary: ia64 x86_64 gaim-1.0.0 PIE fails
Product: [Fedora] Fedora Reporter: Warren Togami <wtogami>
Component: gaimAssignee: Daniel Reed <djr>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: drepper, eblanton, jakub, lschiere+bugs, mark, stu, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 14:28:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 123268    

Description Warren Togami 2004-09-26 07:30:25 UTC
Description of problem:
http://people.redhat.com/wtogami/temp/gaim-1.0.0-4.src.rpm
I attempted to build gaim as PIE, but it fails on x86_64 and ia64
while succeeds on i386, ppc, ppc64, s390, s390x.  Indications are that
this is the result of a libtool problem.  The below hunk is the only
change since 1.0.0-3

@@ -114,7 +114,7 @@
 # disable gnutls explicitly for binary reproducibility to avoid surprises
 # disable tcl and tk because nobody uses it
 %configure --disable-tcl --disable-tk --enable-gnutls=no
--enable-nss=yes $WITH_KRB
-make %{?_smp_mflags}
+make %{?_smp_mflags} CFLAGS="$RPM_OPT_FLAGS -fPIE" LDFLAGS="-pie"
 
 %install
 rm -rf $RPM_BUILD_ROOT

Things I have tried and failed:
1) libtoolize --force with latest FC3 libtool.
2) s/-fPIE/-Wc,-fPIE/ 


http://people.redhat.com/wtogami/temp/gaim-457634-x86_64-loma.build.redhat.com.log
/bin/sh ../../libtool --silent --mode=link x86_64-redhat-linux-gcc 
-O2 -g -pipe -m64 -fPIE  -pie -o docklet.la -rpath /usr/lib64/gaim
-module -avoid-version eggtrayicon.lo docklet.lo docklet-x11.lo  -lnsl 
/usr/bin/ld: .libs/eggtrayicon.o: relocation R_X86_64_PC32 against
`egg_tray_icon_get_type' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


http://people.redhat.com/wtogami/temp/gaim-457714-ia64-bullwinkle.build.redhat.com.log
/bin/sh ../../libtool --silent --mode=link ia64-redhat-linux-gcc  -O2
-g -pipe -fPIE  -pie -o docklet.la -rpath /usr/lib/gaim -module
-avoid-version eggtrayicon.lo docklet.lo docklet-x11.lo  -lnsl 
/usr/bin/ld: .libs/docklet.o: @gprel relocation against dynamic symbol
handle
/usr/bin/ld: .libs/docklet.o: @gprel relocation against dynamic symbol
handle
/usr/bin/ld: .libs/docklet.o: @gprel relocation against dynamic symbol
handle
/usr/bin/ld: .libs/docklet.o: @gprel relocation against dynamic symbol
handle
/usr/bin/ld: .libs/docklet.o: @gprel relocation against dynamic symbol
handle
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

Comment 1 Warren Togami 2004-09-26 10:01:14 UTC
<jakub> warren: some arches allow non-fpie objects in -pie binaries
<jakub> warren: look at DT_TEXTREL tag on PIEs, if it is set in
readelf -d output, it was built wrongly

[builder@fedora64 .libs]$ readelf -d eggtrayicon.o
[builder@fedora64 .libs]$

<warren> jakub, if readelf -d has absolutely no output, what does that
mean?
<jakub> warren: that would be either non-ELF file, or statically
linked one
<jakub> warren: well, actually for non-ELF it will shout that it is
not ELF and on statically linked will say There is no dynamic section
in this file.
<jakub> warren: I can't imagine where readelf -d would give no output

(Warren tests the same thing on i386, no output there either.)

Comment 2 Warren Togami 2004-09-27 10:05:10 UTC
FC3 Blocker due to multiple votes.


Comment 3 Daniel Reed 2004-09-27 19:17:14 UTC
Libtool drops -pie unless you armor it (LDFLAGS="${LDFLAGS} -Wl,-pie").

The Perl module does not use Libtool, and ignores LDFLAGS entirely.

Even with -fPIC -fPIE added to CFLAGS and -Wl,-pie added to LDFLAGS,
there are still problems. I will try to track down what might be going
wrong today.

If anyone on the Cc: can suggest a way to modify the linker flags used
by the Perl module's build scripts, please do.

Comment 4 Daniel Reed 2004-09-27 20:23:35 UTC
Jakub Jelinek has informed me that libraries and dlopenable modules
should not be compiled/linked in such a modified way, so enabling PIE
can not be done simply by modifying CFLAGS or LDFLAGS.

Comment 5 Jakub Jelinek 2004-09-27 20:26:41 UTC
That's not very much different from -fPIC or -shared.
You also put -fPIC only for objects linked into shared libraries,
and you can't just put -shared into your CFLAGS.

Comment 6 Daniel Reed 2004-09-27 21:07:09 UTC
Current build tools know how to use -fPIC and -shared, but apparently
not -fPIE and -pie :/

It may be that compiling PIE should be handled by Libtool or Automake,
neither of which change is likely in the FC3 time frame.

As for doing a one-off for gaim, is it reasonable to just add -fPIE to
the CFLAGS and -pie to the LDFLAGS in src/Makefile (which generates
the only two installed files in /usr/bin) without modifying the build
files for any of the to-be-installed libraries or dlopenable modules?

Comment 7 Ulrich Drepper 2004-09-27 21:23:39 UTC
> As for doing a one-off for gaim, is it reasonable to just add -fPIE to
> the CFLAGS and -pie to the LDFLAGS in src/Makefile (which generates
> the only two installed files in /usr/bin) without modifying the build
> files for any of the to-be-installed libraries or dlopenable modules?

That is all that is needed anyway.  The dlopen-able code must not be
copmiled with -fpie, it must be compiled with -fpic.  Using
f-pie/f_PIE is a bug!

So, if these directories really contain all the code included into the
executables this is exactly what is needed.  But you must be aware of
archives which are used.  Building on x86-64 or ia64 will tell you.

Comment 8 Daniel Reed 2004-09-30 14:28:04 UTC
This is fixed as of 1.0.0-4.