9999 seems like such a strange version number. Is this really newer that 0.9.7-r1? "emerge" seems to think so... sfnt2fnt.o: In function `main': /var/tmp/portage/wine-9999/work/wine/tools/sfnt2fnt.c:219: undefined reference to `wine_cp_get_table' /var/tmp/portage/wine-9999/work/wine/tools/sfnt2fnt.c:225: undefined reference to `wine_cp_get_table' collect2: ld returned 1 exit status Gentoo Base System version 1.12.4 Portage 2.1.1_rc1-r4 (default-linux/amd64/2006.0, gcc-4.1.1/amd64-vanilla, glibc-2.4-r3, 2.6.17-reiser4-r1-nosmp x86_64) ================================================================= System uname: 2.6.17-reiser4-r1-nosmp x86_64 AMD Athlon(tm) 64 Processor 3200+ Last Sync: Tue, 05 Sep 2006 15:00:01 +0000 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [disabled] app-admin/eselect-compiler: 2.0.0_rc2-r1 dev-lang/python: 2.4.3-r3 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r2 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.60 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-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=x86-64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/share/config/kdm /usr/kde/3.5/shutdown /usr/lib64/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo" CXXFLAGS="-O2 -march=x86-64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LINGUAS="en it es de gr fr jp ga hu ja lt nb fi el pt ro ru sk sl sr sv zh_CN da ja en_GB nl pl" MAKEOPTS="-s -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/overlay /usr/local/gentopia /usr/local/xgl-coffee" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 7zip X a52 aac aalib accessibility acpi ada alsa apache2 arts artswrappersuid asterisk audiofile avahi avi berkdb bitmap-fonts bluetooth browserplugin bzip2 cairo canvas cdda cdr cjk cli commercial crypt css cups dbus dga divx4linux djvu dlloader dri dts dvb dvd dvdr dvdread dvi eds elibc_glibc emboss encode evo exif exscalibar fat ffmpeg firefox flac foomatic-db foomaticdb fortran freetype fuse gcj gdbm gif gimpprint glitz glut gnokii gnome gnutls gphoto2 gpm gstreamer gtk gtk2 hal hfs ieee1394 imlib input_devices_evdev input_devices_keyboard input_devices_mouse ipod ipv6 irda isdnlog jack java jfs joystick jpeg jpeg2k kde kdeenablefinal kdgraphics kerberos kernel_linux kig-scripting ladspa lcd ldap libcaca linguas_da linguas_de linguas_el linguas_en linguas_en_GB linguas_es linguas_fi linguas_fr linguas_ga linguas_gr linguas_hu linguas_it linguas_ja linguas_jp linguas_lt linguas_nb linguas_nl linguas_pl linguas_pt linguas_ro linguas_ru linguas_sk linguas_sl linguas_sr linguas_sv linguas_zh_CN lirc live livecd lm_sensors logitech-mouse lzw lzw-tiff mad mbrola mikmod mono mozcalendar moznocompose moznoirc moznomail mozsvg mp3 mpeg musepack musicbrainz nautilus ncurses nls nntp nptl nptlonly nsplugin ntfs nvidia ogg oggvorbis ole on-the-fly-crypt openexr opengl pam pam_chroot pam_timestamp pcmcia pcre pda pdf pdflib perforce perl php png portaudio postgres povray ppds pppd pwdb python qt qt3 qt4 quicktime rdesktop readline reflection reiser4 reiserfs remote rtsp ruby samba scanner sdl session shout skins smartcard sms sndfile soundtouch speedo speex spell spl sql sqlite ssl stats stream subversion svg symlink tcpd theora tiff timidity truetype truetype-fonts type1-fonts udev unichrome unicode usb userland_GNU v4l v4l2 vcd video_cards_apm video_cards_ark video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_fglrx video_cards_glint video_cards_i128 video_cards_i810 video_cards_mach64 video_cards_mga video_cards_neomagic video_cards_nv video_cards_nvidia video_cards_r128 video_cards_radeon video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo visualization vlm vorbis wifi wxwindows xfs xine xinerama xml xml2 xorg xpm xprint xscreensaver xv xvid xvmc zeroconf zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 96079 [details] output from emerge of wine
-9999 versions are either CVS or SVN builds. These are usually the very latest development versions direct from the developers working copies. These are not supported or gauranteed to build at all. Bugs should be reported directly upstream. If you're trying to use the latest unstable release version, make sure you have the following line (and nothing else on the same line) in /etc/portage/package.keywords: app-emulation/wine Also remove wine from /etc/portage/package.unmask if it's in there. You should be aiming to use an 0.9.x version of wine.
Both wine-9999 and wine-0.9.20 have the same error. I suspect wine-9999 is just a rename of the same package. Perhaps someone thought that 9999 is a number greater than 20050925, because they where doing an ascii comparison instead of a numerical comparison...
I just read Allen's reply. So lets just worry about the 0.9.20 version for now. Bill
(In reply to comment #3) > I suspect wine-9999 is just a rename of the same package. No, it's an unsupported live cvs ebuild. vapier: Please use package.mask instead -* keywording.
Created attachment 96082 [details] output from emerge of wine version 0.9.20
no, i'm not p.masking it
post a log without -s in your MAKEOPTS ... the silent option renders the log output pretty useless
Please specify exactly the command you want me to issue. Is it: MAKEOPTS="-s" emerge app-emulation/wine ??? Bill
(In reply to comment #8) > post a log without -s in your MAKEOPTS ... the silent option renders the log > output pretty useless > I just checked, the MAKEOPTS value durring the build was "-s -j3". You can see that in the output of "emerge --info" I posted. Bill
Created attachment 96172 [details] output from MAKEOPTS="-j3" emerge app-emulation/wine I am not sure what is going on. I see the symbol in libwine.so.
should be there ... i686-pc-linux-gnu-gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -DWINE_UNICODE_API="" -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wpointer-arith -O2 -march=x86-64 -pipe -o cptable.o cptable.c i686-pc-linux-gnu-gcc -shared -Wl,-soname,libwine.so.1 -Wl,--version-script=./wine.map casemap.o collation.o compose.o config.o cptable.o debug.o [......] ../../libs/port/libwine_port.a -ldl -o libwine.so.1.0 run `readelf -s` on those files and post the output as an attachment: /var/tmp/portage/wine-0.9.20/work/wine-0.9.20/libs/wine/cptable.o /var/tmp/portage/wine-0.9.20/work/wine-0.9.20/libs/wine/libwine.so
OK. I understand the problem, and I am working on a patch. The general issue is that the installed version of libwine is being used, instead of the version build with the package. Changing LIBWINE to point to the libwine.so directly solves half the problem, but everything linked with winegcc still has issues. Bill
Created attachment 96208 [details, diff] patch to use the correct version of libwine.so when linking With this patch I was able to build and install. The basic problem is the use of -L$(TOPBUILDDIR)/libs/wine -lwine does not guarentee that libwine.so will be loaded from the specified path. In fact if wine is already installed it won't be! If the old version of wine was binary compatible, then the build suceeded, otherwise the build failed. This problem was solved by using $(TOPBUILDDIR)/libs/wine/libwine.so instead. Unfortunately, winegcc hard codes the use of -lwine, so I had to also modify the winegcc.c. Bill
i dont get it ... gcc/ld search -L paths before system paths, so if you do `gcc -Lfoo -lwine`, then gcc had better well be searching foo/ for libwine.so before /usr/lib
(In reply to comment #15) > i dont get it ... gcc/ld search -L paths before system paths, so if you do `gcc > -Lfoo -lwine`, then gcc had better well be searching foo/ for libwine.so before > /usr/lib > Lets consider the following example: gcc ... --nostdlib -Lfi -Lfoo -lwine ... In this case, gcc has been told to look for libraries in fi and foo. So, if fi/libwine.so exists, gcc will NOT even check for foo/libwine.so. The same would happen if you did: gcc ... --nostdlib -Lfi -lbar -Lfoo -lwine ... fi/libwine.so would still be used, not foo/libwine.so. This becomes even more complicated in the following case: gcc ... -Lfi -Lfoo -lwine ... Now, since there is no '--nostdlib' flag, gcc will also look in locations like /lib, /usr/lib, ... In fact this is exactly what happens. libwine.so has been installed in a standard library path from a previous build. So -Lfoo -lwine will not result in libwine.so being loaded from the directory foo. The gcc manual page says the following about the -L flag: You can mix options and other arguments. For the most part, the order you use doesn't matter. Order does matter when you use several options of the same kind; for example, if you specify -L more than once, the directories are searched in the order specified. So, when you add another library path to gcc with the -L flag, it just appends the list of directories to search in. So the directories in the standard library path are always searched first... Bill
incorrect; the standard lib paths are searched only after all of the -L paths that have been specified ... read further down in the manual and it states that -B, -I, and -L take precedence over both environment variables and the gcc configuration (aka system/standard lib paths) this (rightly fails): mkdir foo touch foo/libc.so echo 'int main(){}' > test.c gcc test.c -Lfoo not to mention so many other things would be completely broken; in fact it'd be impossible to upgrade glibc as it utilizes -B and -L to force linking against the system libs
post the output of `emerge --verbose --info`
(In reply to comment #17) > incorrect; the standard lib paths are searched only after all of the -L paths > that have been specified ... read further down in the manual and it states that > -B, -I, and -L take precedence over both environment variables and the gcc > configuration (aka system/standard lib paths) > > this (rightly fails): > mkdir foo > touch foo/libc.so > echo 'int main(){}' > test.c > gcc test.c -Lfoo > > not to mention so many other things would be completely broken; in fact it'd be > impossible to upgrade glibc as it utilizes -B and -L to force linking against > the system libs > In a perfect world you would be right... The problem is I oversimplified my explaination. Instead of testing what rightly fails, instead test what the wine Makefiles expects to work... % mkdir foo % cd foo % echo "void foo(){}" > test.c % i686-pc-linux-gnu-gcc --shared -fPIC -o libwine.so test.c % cd .. % echo "extern void foo();int main(){foo();return 0;}" > bar.c % i686-pc-linux-gnu-gcc bar.c -Lfoo -lwine You should at this point see an error like: /tmp/ccCdyHyu.o: In function `main': bar.c:(.text+0x12): undefined reference to `foo' collect2: ld returned 1 exit status Meanwhile if you try the commands: % mkdir fi % cd fi % echo "void foo(){}" > test.c % gcc --shared -fPIC -o libwine.so test.c % cd .. % echo "extern void foo();int main(){foo();return 0;}" > bar.c % gcc bar.c -Lfi -lwine You will see success. What is possibly the difference you ask? When you are using i686-pc-linux-gnu-gcc you are doing a cross compile. In a cross compile environment standard library paths come first. When using "gcc" you are doing a native compile, so standard library paths come last. Bill
Hmmm. I guess this is more complicated than I thought. It occured to me my test with "gcc" would pass regardless of library search order, because libwine.so is is in /usr/lib32. I did more testing and I found the real problem lies not that libwine.so is in /usr/lib32 but that it is in /emul/linux/x86/usr/lib/libwine.so. Try: mkdir foo cd foo echo "void foo(){}" > test.c i686-pc-linux-gnu-gcc --shared -fPIC -o libwine.so test.c cd .. echo "extern void foo();int main(){foo();return 0;}" > bar.c strace -f -o x i686-pc-linux-gnu-gcc bar.c -Lfoo -lwine grep execv x|tail -1 You will see the /emul/linux/x86/usr/lib path is added with a -L flag when calling ld. This results in this path taking priority over "foo". Bill
Created attachment 96472 [details] output from emerge --verbose --info
are you using eselect-compiler ? do you have an i686 cross-compiler installed ? on amd64, you should not have i686-pc-linux-gnu-gcc in the normal case what you illustrated is a broken toolchain; everything i said is still correct
(In reply to comment #22) > are you using eselect-compiler ? do you have an i686 cross-compiler installed > ? > > on amd64, you should not have i686-pc-linux-gnu-gcc in the normal case > > what you illustrated is a broken toolchain; everything i said is still correct > Possibly you are correct. I did an equery on i686-pc-linux-gnu-gcc, but portage told me it didn't belong to any package. I then tried renaming i686-pc-linux-gnu-gcc, but I then saw simmular errors using x86_64-pc-linux-gnu-gcc. I will try a clean install of gentoo. If I still see errors then too, I will post more details otherwise I will close the bug as invalid. Bill
After doing a fresh install of gentoo, I am nolonger able to produce this problem. So I must conclude this is not a gentoo bug, but a bug with a broken toolchain in Sabayon. Bill
for future reference, make sure you say you are using Sabyon and not Gentoo
I also had this problem and fixed it without reinstalling Gentoo (my toolchain wasn't broken). The fix for me was to remove the /emul directory and all its broken library symlinks and then normal Gentoo ebuild compiled and run fine.
