Bug 133680 - ia64 x86_64 gaim-1.0.0 PIE fails
ia64 x86_64 gaim-1.0.0 PIE fails
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gaim (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Reed
:
Depends On:
Blocks: FC3Target
  Show dependency treegraph
 
Reported: 2004-09-26 03:30 EDT by Warren Togami
Modified: 2007-11-30 17:10 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 10:28:04 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 Warren Togami 2004-09-26 03:30:25 EDT
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 06:01:14 EDT
<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 06:05:10 EDT
FC3 Blocker due to multiple votes.
Comment 3 Daniel Reed 2004-09-27 15:17:14 EDT
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 16:23:35 EDT
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 16:26:41 EDT
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 17:07:09 EDT
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 17:23:39 EDT
> 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 10:28:04 EDT
This is fixed as of 1.0.0-4.

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