Summary: | multilib builds clash with sys-devel/crossdev due to incorrect toolchain being selected | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Slycord <cslycord> |
Component: | [OLD] Library | Assignee: | Gentoo Crossdev team <crossdev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | axs, bertrand, bkohler, crossdev, embedded, gentoo, giuseppe, hasufell, multilib+disabled, nrndda, slyfox, staff, sveneusewig, tl, vapier, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=675566 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 627914 | ||
Attachments: |
build.log
build.log build-amd64.log build-x86.log |
Description
Chris Slycord
2014-02-05 08:00:45 UTC
Created attachment 369574 [details]
build.log
What version of x11-libs/libva is installed? libva needs to be a multilib-build version, in order to have proper LIBVA_DRIVERS paths defined in the *.pc files (esp. the non-native-abi ones). I ensured the [${MULTILIB_USEDEP}] was added to the dependency atoms but that may not have been sufficient to ensure a multilib-build version of libva is installed... Confirmed, something's fishy with the libva install -- you can see in ./configure output that both the x86 and amd64 configure are grabbing the same path from libva.pc , which shouldn't happen. One of these should be /usr/lib32/va/drivers ---- yours: ---- libva-vdpau-driver configuration summary: VA-API version ................... : 0.33.0 VA-API drivers path .............. : /usr/lib64/va/drivers VDPAU version .................... : 1 VDPAU/MPEG-4 support ............. : yes GLX support ...................... : yes libva-vdpau-driver configuration summary: VA-API version ................... : 0.33.0 VA-API drivers path .............. : /usr/lib64/va/drivers VDPAU version .................... : 1 VDPAU/MPEG-4 support ............. : yes GLX support ...................... : yes ---- mine, with libva-1.1.1-r1: ---- libva-vdpau-driver configuration summary: VA-API version ................... : 0.33.0 VA-API drivers path .............. : /usr/lib32/va/drivers VDPAU version .................... : 1 libva-vdpau-driver configuration summary: VA-API version ................... : 0.33.0 VA-API drivers path .............. : /usr/lib64/va/drivers VDPAU version .................... : 1 VDPAU/MPEG-4 support ............. : yes VDPAU/MPEG-4 support ............. : yes GLX support ...................... : yes GLX support ...................... : yes Reinstalling x11-libs/libva-1.1.1-r1 did nothing. It's built with ABI_X86="32 (64) (-x32)" and the /usr/lib32/va directory that you refer to in your comment doesn't exist. Portage 2.2.8-r1 (default/linux/amd64/13.0, gcc-4.8.2, glibc-2.18-r1, 3.13.1-aufs x86_64) ================================================================= System Settings ================================================================= System uname: Linux-3.13.1-aufs-x86_64-Intel-R-_Core-TM-2_CPU_6420_@_2.13GHz-with-gentoo-2.2 KiB Mem: 2029888 total, 575920 free KiB Swap: 2627424 total, 2626856 free Timestamp of tree: Mon, 10 Feb 2014 09:00:01 +0000 ld GNU ld (GNU Binutils) 2.24 distcc 3.1 x86_64-pc-linux-gnu [disabled] ccache version 3.1.9 [enabled] app-shells/bash: 4.2_p45-r1 dev-java/java-config: 2.2.0 dev-lang/python: 2.7.6, 3.2.5-r3, 3.3.3 dev-util/ccache: 3.1.9-r3 dev-util/cmake: 2.8.12.2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.12.4 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.4, 1.14.1 sys-devel/binutils: 2.24-r2 sys-devel/gcc: 4.8.2 sys-devel/gcc-config: 1.8 sys-devel/libtool: 2.4.2 sys-devel/make: 4.0-r1 sys-kernel/linux-headers: 3.13 (virtual/os-headers) sys-libs/glibc: 2.18-r1 Repositories: gentoo mv pipelight local_portage ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.5/ext-active/ /etc/php/cgi-php5.5/ext-active/ /etc/php/cli-php5.5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" DISTDIR="/home/ftp/distfiles" EMERGE_DEFAULT_OPTS="--jobs 4 --load-average 4 --with-bdeps y --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/mv /var/lib/layman/pipelight /usr/local/portage" USE="X aac acl acpi alsa amd64 anthy bash-completion berkdb bluray bzip2 c++0x cairo cdda cddb cdr cjk cli clutter consolekit corefonts cracklib crypt css cxx dbus dri dvd dvdread eds encode ffmpeg flac fontconfig fortran gdbm gif gmp gnome-keyring gstreamer gtk iconv icu immqt-bc ipv6 jpeg jpeg2k lcms libnotify lm_sensors lzma m17n-lib mmx modules mp3 msn multilib musicbrainz nautilus ncurses nls nptl nsplugin ogg opengl openmp pam pch pcre png policykit pulseaudio qemu-ifup qt3support readline schroedinger scim session sse sse2 sse3 ssl ssse3 svg tcpd theora threads tiff truetype twolame udev unicode vaapi vdpau vorbis win32codecs x264 xml xvid xvmc zlib" ABI_X86="64 32" 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" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer nlpsolver pdfimport" LINGUAS="en en_US es es_LA es_MX ja ko zh_CN zh_TW zh" NETBEANS_MODULES="apisupport cnd dlight enterprise ergonomics groovy java javacard javafx mobility php profiler websvccommon" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2 jython2_5" QEMU_SOFTMMU_TARGETS="x86_64 i386" RUBY_TARGETS="ruby18 ruby19 ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="nouveau nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, SYNC, USE_PYTHON ================================================================= Package Settings ================================================================= x11-libs/libva-1.1.1-r1 was built with the following: USE="X drm opengl vdpau -egl -wayland" ABI_X86="32 64 -x32" VIDEO_CARDS="nvidia -dummy -fglrx -intel" The problem then is definitely with libva -- if /usr/lib32/va doesn't exist, then no 32-bit libs were installed when libva-1.1.1-r1[abi_x86_32,abi_x86_64] was installed. Could you please attach the build log for libva? I'm changing this bug summary to match the problem. Created attachment 370240 [details]
build.log
build.log for the successfully installed libva-1.1.1-r1
Created attachment 370242 [details]
build-amd64.log
Created attachment 370244 [details]
build-x86.log
..ok well that's not it, all files are installed for abi_x86_32 as appropriate, from the looks of things.. Could you paste the contents of /usr/lib32/pkgconfig/libva.pc ? it should contain a line "driverdir=/usr/lib32/va/drivers" (In reply to Ian Stakenvicius from comment #10) > ..ok well that's not it, all files are installed for abi_x86_32 as > appropriate, from the looks of things.. > I don't think that's the case: libtool: install: warning: `../../va/libva.la' has not been installed in `/usr/lib32' libtool: install: warning: `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva-x11.la' has not been installed in `/usr/lib32' libtool: install: warning: `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva-drm.la' has not been installed in `/usr/lib32' libtool: install: warning: `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva.la' has not been installed in `/usr/lib32' Those lines appear all over the place in build.log > Could you paste the contents of /usr/lib32/pkgconfig/libva.pc ? it should > contain a line "driverdir=/usr/lib32/va/drivers" It does contain that line. But the directory /usr/lib32/va doesn't exist. ls: cannot access /usr/lib32/va: No such file or directory (In reply to Chris Slycord from comment #11) > (In reply to Ian Stakenvicius from comment #10) > > ..ok well that's not it, all files are installed for abi_x86_32 as > > appropriate, from the looks of things.. > > > I don't think that's the case: > libtool: install: warning: `../../va/libva.la' has not been installed in > `/usr/lib32' > libtool: install: warning: > `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva-x11. > la' has not been installed in `/usr/lib32' > libtool: install: warning: > `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva-drm. > la' has not been installed in `/usr/lib32' > libtool: install: warning: > `/var/tmp/portage/x11-libs/libva-1.1.1-r1/work/libva-1.1.1-x86/va/libva.la' > has not been installed in `/usr/lib32' That's fine, *.la files are unnecessary and get removed anyhow. > > Could you paste the contents of /usr/lib32/pkgconfig/libva.pc ? it should > > contain a line "driverdir=/usr/lib32/va/drivers" > > It does contain that line. But the directory /usr/lib32/va doesn't exist. > > ls: cannot access /usr/lib32/va: No such file or directory That directory won't exist until you install a libva-*-drivers package; the driver package makes the directory path. However, the driver package is informed what path it should make via the libva.pc file, and the issue here seems to be that your libva-vdpau-drivers install is not reading the correct libva.pc file for ABI_X86="32". Unfortunately I cannot reproduce this. If you're still having this issue, can you run: /usr/bin/i686-pc-linux-gnu-pkg-config --variable=driverdir libva ..and see if it gives you a /usr/lib32/va/drivers as output? If it doesn't, I have a sneaking suspicion that your 'x86' pkg-config is broken *** Bug 504234 has been marked as a duplicate of this bug. *** I have the same issue. # cat /usr/lib32/pkgconfig/libva.pc prefix=/usr exec_prefix=${prefix} libdir=/usr/lib32 includedir=${prefix}/include driverdir=/usr/lib32/va/drivers Name: libva Description: Userspace Video Acceleration (VA) core interface Version: 0.34.0 Libs: -L${libdir} -lva Cflags: -I${includedir} and # /usr/bin/i686-pc-linux-gnu-pkg-config libva --variable=driverdir Package libva was not found in the pkg-config search path. Perhaps you should add the directory containing `libva.pc' to the PKG_CONFIG_PATH environment variable No package 'libva' found But /usr/bin/i686-pc-linux-gnu-pkg-config is linked to cross-pkg-config from sys-devel/crossdev. (In reply to Dmitry Derevyanko from comment #15) > But /usr/bin/i686-pc-linux-gnu-pkg-config is linked to cross-pkg-config from > sys-devel/crossdev. This sounds like the root issue. Just to be clear, could you check whether this symlink belongs to a crossdev-installed package or is created by crossdev directly? e.g. using: $ equery b /usr/bin/i686-pc-linux-gnu-pkg-config $ equery b /usr/bin/i686-pc-linux-gnu-pkg-config * Searching for /usr/bin/i686-pc-linux-gnu-pkg-config ... sys-devel/crossdev-20140118 (/usr/bin/cross-pkg-config) I already posted this on multilib@... it is definitely caused by crossdev. The crossdev pkg-config wrapper will overwrite the PKG_CONFIG_LIBDIR variable from env/autotools which then points to PKG_CONFIG_LIBDIR="${SYSROOT}/usr/lib/pkgconfig:${SYSROOT}/usr/share/pkgconfig" so you get in fact the lib64 version of all .pc files... this doesn't cause issues for most of the cases where you just get "-lz" and similar flags, but there are other cases where this breaks a very simple workaround is PKG_CONFIG="pkg-config" emerge -av foo Well, as far as I'm concerned, we can block crossdev completely when multilib is enabled. I'm not sure if this will fix the existing breakages but it will prevent future breakages. Of course, some people will complain. But crossdev is pretty much so mis-designed, it's bound to break your system one way or another, and I don't think it ever provided a sane way of rolling back the damage. (In reply to Michał Górny from comment #19) > Well, as far as I'm concerned, we can block crossdev completely when > multilib is enabled. I'm not sure if this will fix the existing breakages > but it will prevent future breakages. > What do you mean by "block"? Multilib was never a replacement for crossdev. (In reply to Julian Ospald (hasufell) from comment #20) > (In reply to Michał Górny from comment #19) > > Well, as far as I'm concerned, we can block crossdev completely when > > multilib is enabled. I'm not sure if this will fix the existing breakages > > but it will prevent future breakages. > > > > What do you mean by "block"? Multilib was never a replacement for crossdev. I mean block the package since it is known to break system in a ways preventing the two to work together. At least until the maintainer cares enough to finally bring crossdev somewhere near a clean state. (In reply to Michał Górny from comment #21) > (In reply to Julian Ospald (hasufell) from comment #20276) > > (In reply to Michał Górny from comment #19277) > > > Well, as far as I'm concerned, we can block crossdev completely when > > > multilib is enabled. I'm not sure if this will fix the existing breakages > > > but it will prevent future breakages. > > > > > > > What do you mean by "block"? Multilib was never a replacement for crossdev. > > I mean block the package since it is known to break system in a ways > preventing the two to work together. At least until the maintainer cares > enough to finally bring crossdev somewhere near a clean state. I disagree. crossdev is in stable arch and you can't just randomly block packages, just because there is a bug and because you did not design everything yourself. The mess is already big enough with all that profile hackery, caused by multilib. The right approach is to bring this up on dev ML and discuss it. (In reply to Julian Ospald (hasufell) from comment #22) > (In reply to Michał Górny from comment #21) > > (In reply to Julian Ospald (hasufell) from comment #20276) > > > (In reply to Michał Górny from comment #19277) > > > > Well, as far as I'm concerned, we can block crossdev completely when > > > > multilib is enabled. I'm not sure if this will fix the existing breakages > > > > but it will prevent future breakages. > > > > > > > > > > What do you mean by "block"? Multilib was never a replacement for crossdev. > > > > I mean block the package since it is known to break system in a ways > > preventing the two to work together. At least until the maintainer cares > > enough to finally bring crossdev somewhere near a clean state. > > I disagree. crossdev is in stable arch and you can't just randomly block > packages, just because there is a bug and because you did not design > everything yourself. The mess is already big enough with all that profile > hackery, caused by multilib. > I'm with hasufell -- there are two specific and very valid cases where crossdev is used that I can think of: 1 - building for completely unrelated arch (ie, for ARM) 2 - acting as a distcc-server for an x86 distcc client I agree that it is unlikely users would have a valid use-case for using crossdev to implement multilib on an amd64 system; the solution to me would seem to be to somehow ensure crossdev stays out of the native local emerge environment. (i have to brush up on my crossdev usage, but i think this is feasible; i'm fairly certain that for proper crossdev building one usually needs to override various parts of the environment anyhow) CC:ing crossdev maintainers thread is on dev ML, let us discuss there this isn't a new issue. it's been reported in the past, albeit noticed by a lot fewer people due to only a few packages utilizing multilib. +1 for blocking crossdev altogether in multilib eclasses. (In reply to Julian Ospald (hasufell) from comment #27) this bug isn't for discussion. use the mailing list. but please focus on making useful statements rather than ignoring the actual issues in play. *** Bug 511448 has been marked as a duplicate of this bug. *** *** Bug 513370 has been marked as a duplicate of this bug. *** more breakage: in x11-libs/motif-2.3.4-r2: emake -C tools/wml CC="$(tc-getBUILD_CC)" LIBS="-lfl" wmluiltok causes CC to be the x86 crossdev toolchain *** Bug 672234 has been marked as a duplicate of this bug. *** *** Bug 672894 has been marked as a duplicate of this bug. *** media-libs/harfbuzz-2.0.2 seems to be affectged by this (cf. Bug #672894, which has been marked as a duplicate of this one). Can I somehow help to fix this? And: How can I build the package?! (In reply to Tobias Leupold from comment #34) > media-libs/harfbuzz-2.0.2 seems to be affectged by this (cf. Bug #672894, > which has been marked as a duplicate of this one). Can I somehow help to fix > this? I'll add a guard into crossdev against overriding native $CHOSTs. > And: How can I build the package?! You will need to uninstall crossdev-installed toolchain and repair the system. Thanks for the help, I simply removed crossdev, build harfbuzz sucessfully and re-emerged crossdev afterwards. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=1ebd639ccc8605f3e69b5973788101264902559e commit 1ebd639ccc8605f3e69b5973788101264902559e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-12-22 22:29:39 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-12-22 22:29:39 +0000 crossdev: refuse to install crossdev on all CHOST ABIs, not just default In bug #500338 attempt to install toolchain for secondary ABY (x86 on amd64 system) clobbered native tools with tools that target --systroot=/usr/${CTARGET}. That is never an intended state. Block all CHOSTs and suggest using sys-devel/multilib-gcc-wrapper for distcc-like workloads. Bug: https://bugs.gentoo.org/500338 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c78e1daac0af88ccf33bade04aa3b077205ea6dd commit c78e1daac0af88ccf33bade04aa3b077205ea6dd Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-12-22 22:36:23 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-12-22 22:36:42 +0000 sys-devel/crossdev: bump up to 20191222 3 user-visible changes: - refuse to install crossdev on all CHOST ABIs, not just default (bug #500338) - drop Sony Playstation 2 aliases (ee, dvp, iop) - drop mingw32 reference Reported-by: Chris Slycord Closes: https://bugs.gentoo.org/500338 Package-Manager: Portage-2.3.82, Repoman-2.3.20 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20191222.ebuild | 36 +++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+) |