When emerging, "/usr/lib/python2.4/config/libpython2.4.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC " Reproducible: Always Steps to Reproduce: 1.emerge scribus Actual Results: x86_64-pc-linux-gnu-g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -march=k8 -O2 -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -Wno-non-virtual-dtor -L/usr/lib/python2.4/config -lpython2.4 -lpthread -lm -lutil -ldl -module -o libscriptplugin.la -rpath /usr/lib64/scribus/plugins -version-info 0:0:0 cmdcolor.lo cmddialog.lo cmddoc.lo cmdgetprop.lo cmdgetsetprop.lo cmdmani.lo cmdmisc.lo cmdobj.lo cmdpage.lo cmdsetprop.lo cmdtext.lo cmdutil.lo guiapp.lo objimageexport.lo objpdffile.lo objprinter.lo pconsole.lo runscriptdialog.lo scriptercore.lo scripterprefsgui.lo scriptplugin.lo svgimport.lo valuedialog.lo runscriptdialog.moc.lo scriptplugin.moc.lo -lnsl /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/python2.4/config/libpython2.4.a(abstract.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib/python2.4/config/libpython2.4.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[5]: *** [libscriptplugin.la] Erreur 1 make[5]: quittant le répertoire « /var/tmp/portage/app-office/scribus-1.3.3.3/work/scribus-1.3.3.3/scribus/plugins/scriptplugin » make[4]: *** [all-recursive] Erreur 1 make[4]: quittant le répertoire « /var/tmp/portage/app-office/scribus-1.3.3.3/work/scribus-1.3.3.3/scribus/plugins/scriptplugin » make[3]: *** [all-recursive] Erreur 1 make[3]: quittant le répertoire « /var/tmp/portage/app-office/scribus-1.3.3.3/work/scribus-1.3.3.3/scribus/plugins » make[2]: *** [all-recursive] Erreur 1 make[2]: quittant le répertoire « /var/tmp/portage/app-office/scribus-1.3.3.3/work/scribus-1.3.3.3/scribus » make[1]: *** [all-recursive] Erreur 1 make[1]: quittant le répertoire « /var/tmp/portage/app-office/scribus-1.3.3.3/work/scribus-1.3.3.3 » make: *** [all] Erreur 2 !!! ERROR: app-office/scribus-1.3.3.3 failed. Call stack: ebuild.sh, line 1611: Called dyn_compile ebuild.sh, line 968: Called qa_call 'src_compile' environment, line 3258: Called src_compile scribus-1.3.3.3.ebuild, line 29: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-office/scribus-1.3.3.3/temp/build.log'. See forum topic http://forums.gentoo.org/viewtopic-t-534833-highlight-scribus.html
emerge --info, please.
(In reply to comment #1) > emerge --info, please. > Portage 2.1.2-r3 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.19-gentoo-r4 x86_64) ================================================================= System uname: 2.6.19-gentoo-r4 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System release 1.12.9 Timestamp of tree: Thu, 25 Jan 2007 19:50:01 +0000 ccache version 2.4 [disabled] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r1 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ http://85.25.128.62 http://194.117.143.70" LC_ALL="fr_FR.UTF-8" LINGUAS="fr en" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X alsa amd64 apache2 arts audiofile avi berkdb bitmap-fonts bzip2 cdr cli cracklib crypt ctype cups dba dlloader dri eds emboss encode esd ethereal exif expat fam fastbuild ffmpeg foomaticdb force-cgi-redirect fortran ftp gd gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml hal iconv idn imlib ipv6 isdnlog java jpeg kde lcms lzw lzw-tiff mad memlimit mng mozilla mp3 mpeg ncurses nls nptl nptlonly nsplugin opengl pam pcre pdflib perl png posix ppds pppd python qt qt3 qt4 quicktime readline reflection samba sdl session simplexml soap sockets spell spl ssl tcltk tcpd tiff tokenizer truetype truetype-fonts type1-fonts udev unicode usb userlocales vorbis xine xml xml2 xorg xpm xsl xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="fr en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
Have you tried 1.3.3.7? If that works, then we should consider a new stable marking round.
(In reply to comment #3) > Have you tried 1.3.3.7? If that works, then we should consider a new stable > marking round. > Yes, in fact I tried 1.3.3.7 first before trying stable version. They both failed :-(
Craig, can you have a look?
The problem is the -L/usr/lib/python2.4/config. There is a libpython2.4.a in /usr/lib/python2.4/config, but the .so which you are looking for is in /usr/lib itself. Find out where it comes from and drop it, or, alternatively, have python provide a symlink to the .so in python2.4/config so that the .a is no longer picked up.
(In reply to comment #6) > The problem is the -L/usr/lib/python2.4/config. There is a libpython2.4.a in > /usr/lib/python2.4/config, but the .so which you are looking for is in /usr/lib > itself. Find out where it comes from and drop it, or, alternatively, have > python provide a symlink to the .so in python2.4/config so that the .a is no > longer picked up. > I look to the /var/tmp/portage/app-office/scribus-1.3.3.7/work/scribus-1.3.3. 7/config.log and configure and I think it didn't took /usr/lib64 as searching dir. (line is python_libdirs="$ac_python_dir/lib$kdelibsuff /usr/lib$kdelibsuff /usr/local /us r/lib$kdelibsuff $kde_extra_libs" ) Perhaps the option --enable-libsuffix should be set with amd 64 ?
I tried EXTRA_ECONF="--enable-libsuffix=64" emerge scribus and it worked. I think the ebuild should be fixed...
yes you need the suffix setting for amd64 for sure
Also, please forget 1.3.3.3 and concentrate on 1.3.3.7, we will not fix 1.3.3.3. 1.3.3.8 is in string freeze and due for release in 3 weeks (mainly a string update). If you have anything in the way of patches, please send them through and I will get them into CVS for 1.3.3.8. Thanks for your support of Scribus. :)
This is not about scribus but about python. Python guys: (In reply to comment #6) > The problem is the -L/usr/lib/python2.4/config. There is a libpython2.4.a in > /usr/lib/python2.4/config, but the .so which you are looking for is in /usr/lib > itself. Find out where it comes from and drop it, or, alternatively, have > python provide a symlink to the .so in python2.4/config so that the .a is no > longer picked up. Do you have anything against that idea?
I ran into something similar entirely "internal" to python 2.5 earlier (distutils generating linker command lines with that "config" dir in a -L) and the (upstream) fix for that one was to not add that dir to the linker search path. So afaik the right thing to do is to tell your app not to link to the lib in that config dir, instead picking the one in the normal libdir. So: (In reply to comment #11) > This is not about scribus but about python. > > Find out where it comes from and drop it, Yes please. > > or, alternatively, havepython provide a symlink to the .so in > > python2.4/config so that the .a is no longer picked up. I would prefer not doing that since it deviates from how upstream (python.org) installs python.
Thanks Marien. I actually already found the violator: Python $ python-config --libs -lpython2.4 -lm -L/usr/lib64/python2.4/config Are you sure that /usr/lib64/python2.4/config is not supposed to be searched through by apps that want to link against it? I'm just asking because I don't see why python would propagate that path then.
The python-config script installed by python 2.4 is not from upstream, it's a gentoo-specific script (although as far as I know other distros install something similar). So the result you're getting could be a bug in that script. But when I tried python-config from python 2.5 (which *is* provided by upstream) I got that config dir too: python-config --ldflags -L/usr/lib/python2.5/config -lpthread -ldl -lutil -lm -lpython2.5 But a bug I filed against a similar problem in 2.5's distutils (http://sourceforge.net/tracker/index.php?func=detail&aid=1600860&group_id=5470&atid=105470) contains a comment > I think I wrongfully assumed $prefix/lib/pythonX.Y/config contained > a shared python library in addition to the static one. > It seems that was an Ubuntu specific thing :| I don't want to make that an ubuntu+gentoo-specific thing unless upstream agrees it's a good idea. So I filed http://sourceforge.net/tracker/index.php?func=detail&aid=1655392&group_id=5470&atid=105470 for this.
Seems like there is no movement on the upstream bug. I think we should make a decision. If upstream tends to disagree we can always change it again. Marien, what do you think?
I propose to patch python-config so it double checks if a .so library is in prefix/lib As the same python-config says: # add the prefix/lib/pythonX.Y/config dir, but only if there is no # shared library in prefix/lib/. And assuming libpython shared library should always be created when emerging python, then I propose to patch python-config with the patch Best regards
Created attachment 160241 [details, diff] Patch for python-config to double check libpython shared lib presence
(In reply to comment #17) > Created an attachment (id=160241) [edit] > Patch for python-config to double check libpython shared lib presence > Looks like work needs to be done here. Removing amd64@g.o from CC. Add us back with a clear test plan if needed. I can't tell what is desired from the amd64 team.
This bug seems to be fixed in dev-lang/python:2.5.
