I explained almost everything in the Wine's Bugzilla: http://bugs.winehq.org/show_bug.cgi?id=4891 It works if I edit the ebuild like this: ---------------------------------------------------------------------- --- /usr/portage/app-emulation/wine/wine-0.9.23.ebuild 2006-10-13 23:12:43.000000000 +0200 +++ wine-0.9.23.ebuild 2006-10-16 03:50:00.000000000 +0200 @@ -101,6 +101,7 @@ # $(use_enable amd64 win64) econf \ + --libdir=/usr/lib \ --sysconfdir=/etc/wine \ $(use_with ncurses curses) \ $(use_with opengl) \ ---------------------------------------------------------------------- I tried to change --libdir with both 0.9.22 and 0.9.23, and they worked. Portage 2.1.1-r1 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.4-r3, 2.6.17-gentoo-r8 x86_64) ================================================================= System uname: 2.6.17-gentoo-r8 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.12.5 Last Sync: Sat, 14 Oct 2006 00:50:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] 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.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.13-r4 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="-O3 -march=athlon64 -fprefetch-loop-arrays -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/share/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O3 -march=athlon64 -fprefetch-loop-arrays -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="it_IT.UTF-8" LC_ALL="it_IT.UTF-8" LINGUAS="it" 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="amd64 S3TC apache2 bash-completion bdf berkdb bitmap-fonts cli crypt cups dbus dlloader dri elibc_glibc fortran gdbm gimp gimpprint glibc-omitfp gpm hou imap input_devices_aiptek input_devices_hyperpen input_devices_keyboard input_devices_mouse isdnlog kernel_linux kqemu libg++ linguas_it linuxthreads-tls lirc_devices_pctv maildir moznocompose moznoirc moznomail ncurses nls no-old-linux nptl nptlonly pam pcre perl ppds pppd python readline reflection sasl session spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode userland_GNU userlocales video_cards_fglrx video_cards_radeon vorbis xorg zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS
uhh, no if wine breaks with a libdir value of != /usr/lib, then something is broken in wine
I reopened the bug there. Anyway, is --libdir=/usr/lib32 useful? Couldn't it be /usr/lib, at least until this bug is resolved? I have this problem since version 0.9.9, and changing --libdir works for that version too.
no /usr/lib on amd64 is for 64bit (aka native) binaries /usr/lib32 is for 32bit (aka multilib/x86) binaries
Is this still relevant or rather should be closed?
(In reply to comment #4) > Is this still relevant or rather should be closed? Still relevant. Same behaviour with Wine 1.3.19 .
> Is this still relevant or rather should be closed?
Still relevant with Wine 1.7.38 .
After reading comments here and upstream, I think this is not our problem. Programs should run with any libdir; that's the whole point of having it configurable.