libmesh ftbfs on powerpc (ffmpeg not built with -fPIC)

Bug #654666 reported by Matthias Klose on 2010-10-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ffmpeg (Ubuntu)
libmesh (Ubuntu)

Bug Description

----------- Configuring libMesh -------------
checking build system type... powerpc-unknown-linux-gnu
checking host system type... powerpc-unknown-linux-gnu
checking target system type... powerpc-unknown-linux-gnu
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in `/home/doko/tmp/libmesh-0.6.3.dfsg~rc1':
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

configure:3019: /usr/bin/mpicxx -o conftest -g -O2 -Wl,-soname,,-lpe
tsc,-lpetscdm,-lpetscksp,-lpetscmat,-lpetscsnes,-lpetscvec,-lscotchmetis,-lvtkIO conf
test.cpp >&5
configure:3023: $? = 0
configure:3030: ./conftest
./conftest: error while loading shared libraries: /usr/lib/altivec/ R
_PPC_REL24 relocation at 0x0c2b3dfc for symbol `memset' out of range
configure:3034: $? = 127
configure:3041: error: in `/home/doko/tmp/libmesh-0.6.3.dfsg~rc1':
configure:3045: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.

<siretart> from the bug: "As far as I understand it, the ppc problem is not because shared libs have to be pic but because relocations are too "big" when loaded from some libraries (ffplay/ffmpeg seems to work and load the same library)."
<siretart> from the gentoo bug
<siretart> a similar (toolchain) bug can be seen on ia64, btw
<siretart> see debian bug #598952
<ubottu> Debian bug 598952 in src:ffmpeg "ffmpeg: FTBFS on ia64: relocation truncated to fit: GPREL22 against `.bss'" [Serious,Open]
<siretart> cjwatson: regarding re-compiling with pic: if you want to do that, I'd suggest to patch the configure script, it has a hardcoded list of architecture that require -fPIC.

Matthias Klose (doko) on 2010-10-04
Changed in libmesh (Ubuntu):
importance: Undecided → High
milestone: none → maverick-updates
status: New → Confirmed
Matthias Klose (doko) wrote :

> > Non-PIC code in shared libraries is supposed to work, most of the time
> > (and certainly well enough for the binutils testsuite) on powerpc-linux.
> Ok, what is correct now? Or has this change in the last years?

The two statements "libraries not compiled with -fpic or -fPIC are not
guaranteed to work" and "Non-PIC code in shared libraries is supposed
to work, most of the time" are not contradictory. It's supposed to
work most of the time.

The actual constraint is that you can't have more than 16M of object
code and data in your program. To be precise, you'll get 'out of
range' errors if your process image has two routines that are more
than 16M away from each other. The most likely reason this might
happen is that your program really is larger than 16M, the second-most
likely is that you've somehow managed to trick glibc's heuristics for
loading shared libraries into loading a library in the wrong place.
The third-most likely reason is complicated and involves weak

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package ffmpeg - 4:0.6-2ubuntu4

ffmpeg (4:0.6-2ubuntu4) maverick; urgency=low

  * Configure with --enable-pic on powerpc. LP: #654666.
 -- Matthias Klose <email address hidden> Mon, 04 Oct 2010 19:39:46 +0200

Changed in ffmpeg (Ubuntu Maverick):
status: New → Fix Released
Matthias Klose (doko) wrote :

libmesh rebuilt

Changed in libmesh (Ubuntu Maverick):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers