libmesh ftbfs on powerpc (ffmpeg not built with -fPIC)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| ffmpeg (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
| Maverick |
Fix Released
|
Undecided
|
Unassigned | ||
| libmesh (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
| Maverick |
Fix Released
|
High
|
Unassigned | ||
Bug Description
-------
----------- Configuring libMesh -------------
-------
checking build system type... powerpc-
checking host system type... powerpc-
checking target system type... powerpc-
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/
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,
tsc,-lpetscdm,
test.cpp >&5
configure:3023: $? = 0
configure:3030: ./conftest
./conftest: error while loading shared libraries: /usr/lib/
_PPC_REL24 relocation at 0x0c2b3dfc for symbol `memset' out of range
configure:3034: $? = 127
configure:3041: error: in `/home/
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] http://
<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.
| Changed in libmesh (Ubuntu): | |
| importance: | Undecided → High |
| milestone: | none → maverick-updates |
| status: | New → Confirmed |
| Matthias Klose (doko) wrote | #1 |
| Launchpad Janitor (janitor) wrote | #2 |
| Changed in ffmpeg (Ubuntu Maverick): | |
| status: | New → Fix Released |
| Matthias Klose (doko) wrote | #3 |
| Changed in libmesh (Ubuntu Maverick): | |
| status: | Confirmed → Fix Released |
http://
> > 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?
> http://
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
symbols.