test -z "/usr/lib64/vlc/access" || /bin/mkdir -p "/var/tmp/portage/media-video/vlc-0.8.6/image//usr/lib64/vlc/access" /bin/sh ../../../libtool --mode=install /bin/install -c 'libaccess_mms_plugin.la' '/var/tmp/portage/media-video/vlc-0.8.6/image//usr/lib64/vlc/access/libaccess_mms_plugin.la' libtool: install: warning: relinking `libaccess_mms_plugin.la' (cd /var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms; /bin/sh ../../../libtool --tag=CC --mode=relink x86_64-pc-linux-gnu-gcc -D_FILE_OFFSET_BITS=64 -D__USE_UNIX98 -D_LARGEFILE64_SOURCE -D_REENTRANT -D_THREAD_SAFE -D_GNU_SOURCE -DLOCALEDIR="/usr/share/locale" -DDATA_PATH="/usr/share/vlc" -DPLUGIN_PATH="/usr/lib64/vlc" -O3 -ffast-math -funroll-loops -mtune=athlon64 -fomit-frame-pointer -D__VLC__ -D__PLUGIN__ -DMODULE_NAME=access_mms -DMODULE_NAME_IS_access_mms -Wsign-compare -Wall -march=k8 -Os -pipe -msse3 -pipe -L/usr/lib64 -shared -lpthread -rpath /usr/lib64/vlc/access -avoid-version -module -shrext .so -Wl,-O1 -Wl,--as-needed -o libaccess_mms_plugin.la libaccess_mms_plugin_la-mms.lo libaccess_mms_plugin_la-mmsh.lo libaccess_mms_plugin_la-mmstu.lo libaccess_mms_plugin_la-buffer.lo libaccess_mms_plugin_la-asf.lo ../../../src/libvlc.la -inst-prefix-dir /var/tmp/portage/media-video/vlc-0.8.6/image/) x86_64-pc-linux-gnu-gcc -shared .libs/libaccess_mms_plugin_la-mms.o .libs/libaccess_mms_plugin_la-mmsh.o .libs/libaccess_mms_plugin_la-mmstu.o .libs/libaccess_mms_plugin_la-buffer.o .libs/libaccess_mms_plugin_la-asf.o -L/usr/lib64 -lpthread -L/var/tmp/portage/media-video/vlc-0.8.6/image//usr/lib64 -lvlc -mtune=athlon64 -march=k8 -msse3 -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,libaccess_mms_plugin.so -o .libs/libaccess_mms_plugin.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libvlc.a(libvlc_a-item-ext.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libvlc.a: could not read symbols: Bad value collect2: ld returned 1 exit status libtool: install: error: relink `libaccess_mms_plugin.la' with the above command before installing it make[9]: *** [install-libvlcLTLIBRARIES] Error 1 make[9]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms' make[8]: *** [install-exec-local] Error 2 make[8]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms' make[7]: *** [install-am] Error 2 make[7]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms' make[6]: *** [install-recursive] Error 1 make[6]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms' make[5]: *** [install] Error 2 make[5]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access/mms' make[4]: *** [install-recursive] Error 1 make[4]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access' make[3]: *** [install] Error 2 make[3]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules/access' make[2]: *** [install-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6/modules' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/vlc-0.8.6/work/vlc-0.8.6' make: *** [install] Error 2
Portage 2.1.2_rc3-r1 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.18-ck1-r1 x86_64) ================================================================= System uname: 2.6.18-ck1-r1 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.6 Last Sync: Sun, 10 Dec 2006 15:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -Os -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=k8 -Os -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig cached-virtuals distlocks metadata-transfer nostrip sandbox sfperms strict" GENTOO_MIRRORS="http://ftp.snt.utwente.nl/pub/os/linux/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" INSTALL_MASK="/usr/bin/emerge" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en nl" MAKEOPTS="-j2" 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 /usr/local/nouveau /usr/portage/local/layman/xeffects /usr/portage/local/layman/sunrise /usr/portage/local/layman/pro-audio /usr/portage/local/layman/science /usr/portage/local/layman/WTK-Testing" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="amd64 X Xaw3d accessibility alsa alsa_cards_ice1724 aotuv berkdb bitmap-fonts cairo caps cdr cli cracklib crypt cups dbus dhcp dlloader dri dvd dvdr eds elibc_glibc emboss encode fam firefox flac fortran gdbm gif gimpprint gpm gstreamer gtk gtk2 hal iconv input_devices_keyboard input_devices_mouse ipv6 isdnlog jack jpeg kernel_linux ldap libg++ linguas_en linguas_nl mad mikmod minimal mp3 mpeg musepack ncurses nls nptl nptlonly nvidia offensive ogg oggvorbis opengl pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl session spell spl ssl svg tcpd truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l v4l2 video_cards_nouveau video_cards_nv vorbis xml xorg xv xvmc zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, LANG, PORTAGE_RSYNC_EXTRA_OPTS
Is this vlc-0.8.6_beta2 or vlc-0.8.6_rc1?
Oh, i thought i had already replied (maybe it got lost somehow). There is only 0.8.6 in portage, no RC's or beta's.
(In reply to comment #3) > Oh, i thought i had already replied (maybe it got lost somehow). > > There is only 0.8.6 in portage, no RC's or beta's. > Same here - vlc-0.8.6 on ~amd64. Sincerely, Gour
Also seen here lucy ~ # emerge --info Portage 2.1.2_rc3-r2 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r1lucy x86_64) ================================================================= System uname: 2.6.19-gentoo-r1lucy x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.6 Last Sync: Mon, 11 Dec 2006 08:20:01 +0000 dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -pipe -O2" 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 /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=k8 -pipe -O2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://ftp.heanet.ie/pub/gentoo/ ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/" LANG="en_GB" LC_ALL="en_GB" LINGUAS="en_GB" MAKEOPTS="-j2" 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" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac acl alsa alsa_cards_intel8x0 apache2 asf avi bash-completion berkdb bitmap-fonts bzip2 cdr cli cracklib crypt cups curl dbm dga dlloader dri dvd dvdr elibc_glibc emacs exif fbcon ffmpeg flac fortran gd gdbm ggi gif glut glx gnome gnutls gphoto2 gpm gs gstreamer gtk gtk2 hal iconv imagemagick imap imlib input_devices_keyboard input_devices_mouse ipv6 isdnlog jack java jpeg jpeg2k kde kdeenablefinal kernel_linux ldap lesstif libg++ linguas_en_GB lm_sensors mad mbox milter mmap motif mozilla mp3 mpeg ncurses nptl nptlonly nsplugin odbc ogg opengl pam pcre pdf pdflib perl plotutils png postgres ppds pppd python qt qt3 quicktime readline reflection samba scanner session slp speex spell spl ssl svg swat tcpd threads tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_fglrx video_cards_radeon vorbis wmf wxwindows xemacs xine xml xml2 xorg xpm xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Having looked a bit closer - the problem looks like it's linking against the old /usr/lib64/libvlc.a. Removing -L/usr/lib64 from that compile allows it to complete by linking against the newly built lib. Not sure how to fix the ebuild tho'.
(In reply to comment #6) > Having looked a bit closer - the problem looks like it's linking against the > old /usr/lib64/libvlc.a. Removing -L/usr/lib64 from that compile allows it to > complete by linking against the newly built lib. Not sure how to fix the ebuild > tho'. > I've solved it unmerging vlc and then re-emerging it.
verified removing previous vlc and emerging new VLC works
(In reply to comment #8) > verified removing previous vlc and emerging new VLC works > Same here. Sincerely, Gour
> I've solved it unmerging vlc and then re-emerging it. this did the trick for me too regards ron
(In reply to comment #7) > I've solved it unmerging vlc and then re-emerging it. Another (slightly more brutal!) hack is to rm /usr/lib/libvlc* beforehand. There's still a bug in the (possibly upstream) build though which might catch people in a future release.
*** Bug 158148 has been marked as a duplicate of this bug. ***
removing /usr/lib/libvlc.a and re-emerging fixed it here too.
same problem here. Unmerging fixed it indeed.
The re-emerge && emerge worked perfectly for me too: Portage 2.1.1-r2 (default-linux/amd64/2006.0, gcc-4.1.1, glibc-2.4-r4, 2.6.16-gentoo-r7 x86_64) ================================================================= System uname: 2.6.16-gentoo-r7 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ Gentoo Base System version 1.12.6 Last Sync: Thu, 11 Jan 2007 12:01:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer -msse3" 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/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=k8 -pipe -fomit-frame-pointer -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirror.switch.ch/mirror/gentoo/" LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de" MAKEOPTS="-j4" 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/overlays/local" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X alsa alsa_cards_snd-intel8x0 alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol berkdb bitmap-fonts browserplugin cdr cli cracklib crypt cups dlloader dri dvb dvd dvdr dvdread eds elibc_glibc emboss encode flac foomaticdb fortran games gif gnome gpm gstreamer gtk gtk2 iconv imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jpeg kde kernel_linux linguas_de lzw lzw-tiff mad mozilla mp3 mpeg mysql ncurses nfs nls nptl nptlonly nsplugin ogg opengl pam pcre pda pdf perl png pppd python qt qt3 qt4 quicktime readline reflection sdk sdl session skins spell spl ssl tcpd tetex tiff truetype truetype-fonts type1-fonts unicode usb userland_GNU video_cards_nvidia wmv wxwindows xine xorg xpm xv zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
*** Bug 161594 has been marked as a duplicate of this bug. ***
same problem here, unmerging/remerging fixed it. (~amd64)
*** Bug 161769 has been marked as a duplicate of this bug. ***
Unmerging vlc and remerging it fixed the problem for me too. Portage 2.1.1-r2 (default-linux/amd64/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.19-gentoo-r2 x86_64) ================================================================= System uname: 2.6.19-gentoo-r2 x86_64 Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz Gentoo Base System version 1.12.6 Last Sync: Sat, 13 Jan 2007 21:20:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig colorgcc distlocks metadata-transfer multilib-strict parallel-fetch prelink sandbox sfperms strict userfetch userpriv usersandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LINGUAS="en" MAKEOPTS="-j3" 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.us.gentoo.org/gentoo-portage" USE="amd64 X a52 aac aalib acpi aim alsa alsa_cards_emu10k1 alsa_pcm_plugins_adpcm alsa_pcm_plugins_alaw alsa_pcm_plugins_asym alsa_pcm_plugins_copy alsa_pcm_plugins_dmix alsa_pcm_plugins_dshare alsa_pcm_plugins_dsnoop alsa_pcm_plugins_empty alsa_pcm_plugins_extplug alsa_pcm_plugins_file alsa_pcm_plugins_hooks alsa_pcm_plugins_iec958 alsa_pcm_plugins_ioplug alsa_pcm_plugins_ladspa alsa_pcm_plugins_lfloat alsa_pcm_plugins_linear alsa_pcm_plugins_meter alsa_pcm_plugins_mulaw alsa_pcm_plugins_multi alsa_pcm_plugins_null alsa_pcm_plugins_plug alsa_pcm_plugins_rate alsa_pcm_plugins_route alsa_pcm_plugins_share alsa_pcm_plugins_shm alsa_pcm_plugins_softvol apache2 bash-completion beagle berkdb bitmap-fonts bittorrent browserplugin bzip2 cairo canna cddb cdparanoia cdr cjk cli cracklib crypt css cups dbus dga dlloader dri dts dvd dvdr dvdread eds elibc_glibc emboss encode esd fam fastcgi ffmpeg firefox flac fortran gcc64 gd gdbm gif gnome gpm gstreamer gtk gtk2 hal iconv imap input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jabber java javascript jpeg kerberos kernel_linux libg++ linguas_en lm_sensors mad maildir mbox mikmod mime mmx2 mono mp3 mpeg mplayer msn ncurses nls nptl nptlonly nsplugin offensive ogg opengl oscar oss pam pcre perl png ppds pppd python quicktime readline reflection samba sdl session speex spell spl ssl startup-notification subtitles svg tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU vcd video_cards_nvidia vim-syntax vorbis xine xinerama xml xorg xosd xpm xv xvid yahoo zip zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Please don't report that the same fix works over and over again. We are aware of it, you are not adding any new information to the bug.
*** Bug 162684 has been marked as a duplicate of this bug. ***
*** Bug 164877 has been marked as a duplicate of this bug. ***
This is actually not a amd64-specific issue. media-video: Comment #6 describes the problem fairly well IMO.
Note: the relinking does _not_ happen on x86.
*** Bug 165477 has been marked as a duplicate of this bug. ***
*** Bug 172092 has been marked as a duplicate of this bug. ***
*** Bug 175725 has been marked as a duplicate of this bug. ***
hmmm ok I think I understand it now : x86_64-pc-linux-gnu-gcc -shared .libs/libaccess_mms_plugin_la-mms.o .libs/libaccess_mms_plugin_la-mmsh.o .libs/libaccess_mms_plugin_la-mmstu.o .libs/libaccess_mms_plugin_la-buffer.o .libs/libaccess_mms_plugin_la-asf.o -L/usr/lib64 -lpthread -L/var/tmp/portage/media-video/vlc-0.8.6/image//usr/lib64 -lvlc -mtune=athlon64 -march=k8 -msse3 -Wl,-O1 -Wl,--as-needed -Wl,-soname -Wl,libaccess_mms_plugin.so -o .libs/libaccess_mms_plugin.so with this -L ordering : -L/usr/lib64 -L/var/tmp/portage/media-video/vlc-0.8.6/image//usr/lib64 the linker is looking in /usr/lib64 *before* the sandbox where the new libvlc is when linking (according to gcc man page, directories given with -L are searched from left to right) it's a bit late to tackle this, but this will probably cause us problems also when moving to vlc 0.9.0 as this version will have its libvlc.so number bumped cause of abi changes (and thus modules will probably be linked against the old libvlc what will most likely cause failures)
this does affect x86. it's just not an error on that arch. i686-pc-linux-gnu-gcc -shared .libs/libgnutls_plugin_la-gnutls.o -Wl,--rpath -Wl,/var/tmp/portage/media-video/vlc-0.8.6b/work/vlc-0.8.6b/src/.libs -L/usr/lib -lpthread /usr/lib/libgcrypt.so /usr/lib/libgnutls.so ../../src/.libs/libvlc.so -march=prescott -Wl,-O1 -Wl,--hash-style=gnu -Wl,-soname -Wl,libgnutls_plugin.so -o .libs/libgnutls_plugin.so
(In reply to comment #29) > this does affect x86. it's just not an error on that arch. but it produces textrels if it includes a non pic .a in a shared lib, I had closed another bug cause of that. Even if it's not an error, it's still a bug. adding base-system as this seems to be a libtool issue : I've not managed to entirely tackle this, but applying the patch $PORTDIR/eclass/ELT-patches/fix-relink/1.5.0 is $S/autotools helps a lot : -L args are better sorted, but that's not yet perfect, I'm at : x86_64-pc-linux-gnu-gcc -shared .libs/libsdl_image_plugin_la-sdl_image.o -L/usr/X11R6/lib64 -L/var/tmp/portage/media-video/vlc-0.8.6b/image/usr//usr/lib64 -L/usr/lib64 -lSDL_image -ltiff -ljpeg -lpng -lz -lSDL -lpthread -lvlc -march=athlon64 -Wl,--as-needed -Wl,-soname -Wl,libsdl_image_plugin.so -o .libs/libsdl_image_plugin.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/X11R6/lib64/libvlc.a(libvlc_a-configuration.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/X11R6/lib64/libvlc.a: could not read symbols: Bad value it could be fine, but /usr/X11R6 points to /usr... Now I have an ugly, but working, patch that allows me to go from vlc 0.8.5 to 0.8.6 without relinking
Created attachment 117852 [details, diff] ltmain.sh ugly patch Here is the patch, it's a small modification of the fix-relink patch, adding -L$inst_prefix_dir$libdir at the beginning. For me it didn't fail, but as libtool code is very hard to understand, I'm not 100% sure that it's safe. If anybody with more libtool knowledge than me could comment on this, that'd help. Anyway, this still seems to be a libtool bug that doesn't sort -L args correctly and thus by installing in a sandbox before unmerging the previous version, it might try to link with old libs.
you tried `elibtoolize` ? if that didnt work, did you try `elibtoolize --reverse-deps` ?
(In reply to comment #32) > you tried `elibtoolize` ? It's already called with eautoreconf > if that didnt work, did you try `elibtoolize > --reverse-deps` ? that is more or less what I was talking about in comment #29, I tried also --reverse-deps by hacking a bit (as elibtoolize had already been called). While I can understand that reversing search paths with fix-relink patch might avoid such breakages in most of the cases, I fail to see how this is a fix. As far as I understand it, we don't care much about -L being ordered or reversed, the only thing we want is -L$inst_prefix_dir$libdir to be the leftmost -L arg passed to the compiler While searching in libtool's mail archives I found this : http://lists.gnu.org/archive/html/bug-libtool/2003-07/msg00002.html I've ported it so it can be applied to ltmain.sh, it prevents some relinking but not all : x86_64-pc-linux-gnu-gcc -shared .libs/libglx_plugin_la-glx.o .libs/libglx_plugin_la-xcommon.o -L/usr/var/tmp/portage/media-video/vlc-0.8.6b/image//usr/lib -L/usr/lib64 -lpthread -lXxf86vm -lXinerama -lSM -lICE -lX11 -lXext -lGL -L/usr/lib -lGLU -lvlc -march=athlon64 -Wl,--as-needed -Wl,-soname -Wl,libglx_plugin.so -o .libs/libglx_plugin.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libvlc.a(libvlc_a-playlist.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /usr/lib64/libvlc.a: could not read symbols: Bad value the ordering seems to be fine, but not compatible with multilib (wrt to the age of the patch, it's probably from times when libtool had bugs with multilib) and there is that in libtool's changelog : 2004-01-23 Scott James Remnant <scott@netsplit.com> * ltmain.in: When relinking, place the -L parameter containing the installation prefix directory after the intended destination, so we don't accidentally link against an older installed library. but it seems that it's not doing it in our case by the way, the ugly patch I had attached is the same as 1.5.0-fix-relink patch except that it really uglyly adds -L$inst_prefix_dir$libdir at the begining of each reordering step
Created attachment 118116 [details, diff] much better patch Interesting enough, porting the patch posted on libtool's ml like that solves the relinking problem and ensures the first -L is the sandbox libdir. However, I don't think it would be wise to add this patch to vlc wrt to different ltmain.sh versions that can be used; any comment is more than welcome
reassigning wrt to comment #34
Just to keep track of it (and before I forget), upgrading from 0.8.6b to a 0.9.0 snapshot of vlc : $ ldd /usr/lib64/vlc/access/libdvb_plugin.so libpthread.so.0 => /lib/libpthread.so.0 (0x00002ba13c7a3000) libdvbpsi.so.4 => /usr/lib/libdvbpsi.so.4 (0x00002ba13c9bd000) libvlc.so.0 => not found libc.so.6 => /lib/libc.so.6 (0x00002ba13cac9000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) libvlc.so.0 is vlc-0.8.6's libvlc while vlc 0.9.0 installs libvlc.so.1 thus libvlc.so.0 gets removed while upgrading. I'll probably have to force 0.8.6 removal when upgrading to 0.9.0 by setting a blocker when we'll have to go to 0.9.0....
*** Bug 181679 has been marked as a duplicate of this bug. ***
Could you try to add --disable-fast install to your configure It has just been commited in upstream VLC. It disable some optimisations (sic) when linking while installing which may well be the trouble here hth
(In reply to comment #38) > Could you try to add --disable-fast install to your configure > > It has just been commited in upstream VLC. > It disable some optimisations (sic) when linking while installing which may > well be the trouble here same with latest svn, with or without --disable-fast-install, when upgrading from 0.8.6c to trunk : ldd /usr/lib64/vlc/access/libdvb_plugin.so libvlc.so.0 => not found
(In reply to comment #33) > (In reply to comment #32) > > you tried `elibtoolize` ? > > It's already called with eautoreconf > > > if that didnt work, did you try `elibtoolize > > --reverse-deps` ? > > that is more or less what I was talking about in comment #29, I tried also > --reverse-deps by hacking a bit (as elibtoolize had already been called). > While I can understand that reversing search paths with fix-relink patch might > avoid such breakages in most of the cases, I fail to see how this is a fix. > It is because that is a hack for broken libtool based builds. And as hacks go, they usually are not perfect. > As far as I understand it, we don't care much about -L being ordered or > reversed, the only thing we want is -L$inst_prefix_dir$libdir to be the > leftmost -L arg passed to the compiler > As far as I can see, the problem is that VLC has a broken libtool based build system. You either use libtool, or don't, not inbetween - else libtool try to be smart, and as it usually assumes you link with -l<lib> to external libs, it gets it wrong. As for the dvb plugin for example, if you look at Makefile.am, they have: ---cut--- LTLIBVLC = -L$(top_builddir)/src -lvlc ... AM_LIBADD = $(LTLIBVLC) ... libdvb_plugin_la_LIBADD = $(AM_LIBADD) ---cut--- Which is correct in a libtool setup up to the point where they use -l to link agains libvlc. It really should be: ---cut--- LTLIBVLC = $(top_builddir)/src/libvlc.la ---cut--- which should get it right. As I assume most if not all the plugins are broken like this, and really do not care about VLC except if the other players cannot play something, I am not going to bother to make a patch.
Created attachment 133272 [details, diff] vlc-0.9.0-svn-libtool-fixes.patch So I was bored. As I said, it should specify libvlc.la in _LIBADD. There is however another problems: - the AC_PATH_XTRA autoconf macro have the nasty side effect of adding /usr/lib64 to the linker search path, even though it is one of the default search paths. So rather use AC_PATH_X. - '-L/usr/lib64' still ends up in libvlc.la. Not sure where this is coming from. To regenerate the module Makefiles, you need to run ./bootstrap. I guess there are two options: - Track the other stray '-L/usr/lib64' (preferred) - or maybe do not use libvlc.la, but change AC_PATH_XTRA to AC_PATH_X (I have however not tested this)
(In reply to comment #41) > Created an attachment (id=133272) [edit] > vlc-0.9.0-svn-libtool-fixes.patch > > So I was bored. As I said, it should specify libvlc.la in _LIBADD. > > There is however another problems: > - the AC_PATH_XTRA autoconf macro have the nasty side effect of adding > /usr/lib64 to the linker search path, even though it is one of the default > search paths. So rather use AC_PATH_X. > - '-L/usr/lib64' still ends up in libvlc.la. Not sure where this is coming > from. > > To regenerate the module Makefiles, you need to run ./bootstrap. I guess there > are two options: > - Track the other stray '-L/usr/lib64' (preferred) > - or maybe do not use libvlc.la, but change AC_PATH_XTRA to AC_PATH_X (I have > however not tested this) thanks for your insight, I've tried that, it has been comitted upstream afaik, but this doesn't fix the relinking problem :/ there is a -L/usr/lib64 coming from vlc-config, I nuked it, but there are still modules that are linked with it, I think that's basically any module which is linked against a lib where pkg-config --libs reports -L/usr/lib{,64} I'll attach a build log
bah cannot attach the build log, it's at : http://dev.gentoo.org/~aballier/vlc_relink.log ldd /usr/lib64/vlc/video_output/libdirectfb_plugin.so [...] libvlc.so.0 => not found [...] libtool: install: warning: relinking `libdirectfb_plugin.la' (cd /var/tmp/portage/media-video/vlc-0.9.0_alpha20071009/work/vlc-0.9.0-svn/modules/video_output; /bin/sh ../../libtool --tag=CC --mode=relink x86_64-pc-linux-gnu-gcc -std=gnu99 -D_FILE_OFFSET_BITS=64 -D__USE_UNIX98 -D_LARGEFILE64_SOURCE -D_REENTRANT -D_THREAD_SAFE -DLOCALEDIR="/usr/share/locale" -DDATA_PATH="/usr/share/vlc" -DPLUGIN_PATH="/usr/lib64/vlc" -O0 -D__LIBVLC__ -D__PLUGIN__ -I/usr/include/directfb -D_REENTRANT -DMODULE_NAME=directfb -DMODULE_NAME_IS_directfb -fvisibility=hidden -march=athlon64 -O2 -pipe -Wall -Wextra -Wno-unused-parameter -Wsign-compare -Wundef -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wmissing-prototypes -Wvolatile-register-var -lpthread -L/usr/lib64 -ldirectfb -lfusion -ldirect -lpthread -lz -ldl -rpath /usr/lib64/vlc/video_output -avoid-version -module -no-undefined -shrext .so -export-dynamic -Wl,--as-needed -o libdirectfb_plugin.la libdirectfb_plugin_la-directfb.lo ../../src/libvlc.la -inst-prefix-dir /var/tmp/portage/media-video/vlc-0.9.0_alpha20071009/image/) x86_64-pc-linux-gnu-gcc -std=gnu99 -shared .libs/libdirectfb_plugin_la-directfb.o -L/usr/lib64 -L/var/tmp/portage/media-video/vlc-0.9.0_alpha20071009/image//usr/lib64 -ldirectfb -lfusion -ldirect -lpthread -lz -ldl -lvlc -march=athlon64 -Wl,--as-needed -Wl,-soname -Wl,libdirectfb_plugin.so -o .libs/libdirectfb_plugin.so note that -L/usr/lib64 is still here $ directfb-config --libs -L/usr/lib64 -ldirectfb -lfusion -ldirect -lpthread -lz -ldl so I still think libtool is at fault here as it fails to reorder correctly -L args
Created attachment 133325 [details, diff] vlc-0.9.0-svn-libtool-fixes.patch Yeah, the problem is that they add the extra libs needed via (in genmf): lib${mod}_plugin_la_LDFLAGS = \`\$(VLC_CONFIG) --libs plugin ${mod}\` \$(AM_LDFLAGS) which injects the '-L/usr/lib64' before libvlc.la. The proper fix would have been to add the extra libs to: lib${mod}_plugin_la_LIBADD = \$(AM_LIBADD) _after_ AM_LIBADD (or libvlc.la then), but automake wont allow this with the current way things work in VLC due to the '--libs' in the arguments to vlc-config. I guess the proper way would be to not use vlc-config, but add variables for the extra libs via autoconf/automake and add that to _la_LIBADD _after_ libvlc.la, but that will be a lot of work. The quick fix thus is to have vlc-config not add -L<libdir> if <libdir> is in gcc's default search path. It is still a bit hackish though, but works. Patch attached.
Created attachment 133327 [details, diff] vlc-0.9.0-ebuild.patch Ebuild patch that do not use ./bootstrap (so not running autoreconf twice).
(In reply to comment #44) > The quick fix thus is to have vlc-config not add -L<libdir> if <libdir> is in > gcc's default search path. It is still a bit hackish though, but works. > > Patch attached. Yep this fixes it ! Thanks ! @xtophe/vlc team: is that patch acceptable for you ? for me it's fine, but I prefer having your opinion on that I have a doubt whether this should be fixed in vlc or deserve to be reported to libtool's people. As I understand libtool's paradigm it's more like "you want to compile a library and dont want to bother about details, no problem we'll do it for you"; from that POV, discarding -L<libdir> when it's in the search path should be the job of libtool; but as vlc seems to be the only package affected by this, I'm not sure.
Created attachment 133338 [details, diff] vlc-0.9.0-svn-libtool-fixes.patch No, its a VLC issue and not a libtool one. The problem as I tried to explain above, is that VLC adds libraries and -L flags to _LDFLAGS instead of _LIBADD, which injects the -L flags in the wrong place. I did the other patch as I could not quickly fix it in a better way due to automake issues, but I sorted them out. Above is a better patch that do not strip any -L flags, and only add the library and -L flags to _LIBADD instead of _LDFLAGS where they are supposed to be.
(In reply to comment #47) > The problem as I tried to explain above, is that VLC adds libraries and -L > flags to _LDFLAGS instead of _LIBADD, which injects the -L flags in the wrong > place. man... I *really* owe you one there, you've spotted the issue when I had failed for ~1 year... afaik LDFLAGS are meant for extra linker options (and perhaps extra libtool options), but definitely not for linking to other libraries which should be in LIBADD. I didn't know vlc was doing it that way and didn't imagine that could cause such weird issues. Thanks a lot! I'll wait for upstream comments and then apply your patch; now I'm sure it's not a libtool issue.
after talking with courmisch it appears that it was really intended to be in _LDFLAGS, because _LIBADD is meant only for -L and -l (according to automake's info section). Apart from hardcoded ldflags in configure.ac, pkg-config --libs can also output some wrong flags; so adding the output of vlc-config --libs to LIBADD can be a not that good idea...
---cut--- $ for y in $(for x in /usr/lib64/pkgconfig/*.pc; do pkg-config --libs $(basename ${x/.pc/}); done | sort -u) ; do case "${y}" in -l*) ;; -L*) ;; *) echo "${y}" ;; esac; done | sort -u -pthread -Wl,--export-dynamic -Wl,-R/usr/lib64 -Wl,-R/usr/lib64/evolution/2.12 -Wl,-R/usr/lib64/mozilla-firefox -Wl,-R/usr/lib64/nspr -Wl,-R/usr/lib64/nss -Wl,-R/usr/lib64/xulrunner ---cut--- Which looks fine to me. The bottom line is that they will keep having these problems if they add them to _LDFLAGS. Only suggestion then that I can make is to use the patch that strips -L flags (attachment #133325 [details, diff]), but that is not really the correct way. If you look at the whole of gnome, they use _LIBADD and it works correctly. If some pkg-config --libs output is not compatible with _LIBADD, then that is a bug to fix if you ask me.
Oh, and as I did remark somewhere, attachment #133338 [details, diff] is a minimal patch to get it working. If vlc-config's --libs could contain ldflags, then they should be split into a seperate --ldflags, or the alternative is to do a major rewrite and not use vlc-config, but as I also noted somewhere, that will be much more work.
I've just commited an ebuild that has courmisch fixes, moving to LIBADD linking stuff, keeping in LDFLAGS real LDFLAGS; now it should be sane. Big thanks for your insight Martin and to courmisch for doing the boring work of splitting LDFLAGS/LIBS
