| Summary: | wine-0.9.20 fails to compile: undefined reference to wine_cp_get_table | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bill C. Riemers <docbill+bugzilla> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gentoo-bugs |
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
output from emerge of wine
output from emerge of wine version 0.9.20 output from MAKEOPTS="-j3" emerge app-emulation/wine patch to use the correct version of libwine.so when linking output from emerge --verbose --info |
||
|
Description
Bill C. Riemers
2006-09-05 09:07:57 UTC
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. |
