FS#27282 - [mxml] build with -fPIC for x86_64
Attached to Project:
Community Packages
Opened by speps (archspeps) - Monday, 28 November 2011, 02:31 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 30 November 2011, 09:22 GMT
Opened by speps (archspeps) - Monday, 28 November 2011, 02:31 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 30 November 2011, 09:22 GMT
|
Details
Description: mxml needs to be built with -fPIC flag to be
linked against on x86_64 architectures.
Otherwise a some builds could fail with: /usr/bin/ld: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libmxml.a(mxml-attr.o): relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../lib/libmxml.a: could not read symbols: Bad value collect2: ld returned 1 exit status A solution is to export -fPIC for x86_64 this way: # fPIC build for x86_64 [ "$CARCH" = x86_64 ] && \ export CFLAGS="$CFLAGS -fPIC" another solution is enable shared libraries: ./configure --prefix=/usr \ --enable-shared when building shared libs -fPIC flag is added automatically. The less invasive solution would be the first one, so other libraries that links against mxml do not need to change the mxml build dependency to an effective dependency. Btw, enabling shared libraries (not built by default) would not be so problematic since packages currently built against it (dunno which one other than zynaddsubfx) will continue working, while relative PKGBUILDs could be updated on the next release too. So, why not enabling shared libs? Additional info: package afflicted -> 2.6-x or previous Steps to reproduce: linking with -lmxml on a x86_64 system or try https://aur.archlinux.org/packages.php?ID=50594 |
This task depends upon
Comment by
Sverd Johnsen (sjohnsen) -
Wednesday, 30 November 2011, 03:29 GMT
Its bad practice to ship non-PIC libraries regardless of arch.