Apache OpenOffice (AOO) Bugzilla – Issue 14044
check_libvcl644li.so: undefined symbol: _Z16XineramaIsActiveP9_XDisplay
Last modified: 2003-10-31 12:29:27 UTC
Hi, I'm trying to test beta2 tag on SuSE Linux 8.0 with: pavel@oo:~> /opt/experimental/bin/gcc -v Reading specs from /opt/experimental/lib/gcc-lib/i486-suse-linux/3.0.4/specs Configured with: ../configure --enable-threads=posix --enable-long-long --prefix=/opt/experimental --with-local-prefix=/usr/local --enable-languages=c,c++,f77,objc,java --disable-nls --enable-shared i486-suse-linux Thread model: posix gcc version 3.0.4 (SuSE) This compiler is used by our team to provide builds of 1.0.3 (and older version) and also Beta1 was compiled by this compiler. But now I got this: /mnt/hdc2/pavel/BuildDir/ooo_11beta2_src/solenv/bin/checkdll.sh -L../unxlngi4.pro/lib -L../lib -L/mnt/hdc2/pavel/BuildDir/ooo_11beta2_src/solenv/unxlngi4/lib -L/mnt/hdc2/pavel/BuildDir/ooo_11beta2_src/solver/644/unxlngi4.pro/lib -L/mnt/hdc2/pavel/BuildDir/ooo_11beta2_src/solenv/unxlngi4/lib -L/usr/lib/java/lib -L/usr/lib/java/jre/lib/i386 -L/usr/lib/java/jre/lib/i386/client -L/usr/lib/java/jre/lib/i386/native_threads -L/usr/X11R6/lib ../unxlngi4.pro/lib/check_libvcl644li.so Checking DLL ../unxlngi4.pro/lib/check_libvcl644li.so ...: ERROR: ../unxlngi4.pro/lib/check_libvcl644li.so: undefined symbol: _Z16XineramaIsActiveP9_XDisplay dmake: Error code 1, while making '../unxlngi4.pro/lib/libvcl644li.so' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /mnt/hdc2/pavel/BuildDir/ooo_11beta2_src/vcl/util dmake: Error code 1, while making 'build_all' ---* TG_SLO.MK *--- Other info: pavel@oo:~/BuildDir/ooo_11beta2_src/vcl> grep -r _Z16XineramaIsActiveP9_XDisplay * Binary file unxlngi4.pro/lib/check_libvcl644li.so matches Binary file unxlngi4.pro/slo/saldisp.o matches unxlngi4.pro/slb/salapp.dump: U _Z16XineramaIsActiveP9_XDisplay unxlngi4.pro/slb/vcl.dump: U _Z16XineramaIsActiveP9_XDisplay pavel@oo:~/BuildDir/ooo_11beta2_src/vcl> nm /usr/X11R6/lib/libXinerama.a |grep XineramaIsActive 0000057c T XineramaIsActive Kevin Hendricks told me that there is a bug in vcl/unx/inc/{post.h,pre.h}. See attached patch.
Created attachment 6014 [details] Kevin's suggestion
Changing target.
cp->pl: mangling problem ? please have a look
actually what is broken is the Xinerama.h distributed by SuSE (in SuSE 8.0, not in 8.1; what devil rode them to remove the extern "C" temporarily from their distribution is beyond me). Applying this patch would introduce a nested extern "C" which is not really good; please use correct X headers instead.
closing
Your statement is completely unfair to SuSE. I hope you will appologize... See http://cvsweb.xfree86.org/cvsweb/xc/include/extensions/Xinerama.h.diff?r1=3.2&r2=3.3 for the reason why there are two different versions of Xinerama.h. One with and other without "extern C". We should handle this somehow, I think. So reopening for solution. The same also applies to Red Hat Linux 7.3: bash-2.05a$ cat /etc/redhat-release Red Hat Linux release 7.3 (Valhalla) bash-2.05a$ grep XFUNCPROTOBEGIN `locate Xinerama.h` bash-2.05a$
I stand corrected, i had only seen the issue on SuSE. Nevertheless if i patch our headers that way, we'd end up with a duplicate extern "C" on systems with correct X headers, which is not really desirable.
Yes, so the patch is wrong and we should implement correct check in configure if that function needs extern C or not. But this should be solved. Without that we do not support Red Hat Linux 7.3 and SuSE Linux 8.0 and probably many other distributions that used that particular version of XFree86. Or we could just clearly state that we do not support those distributions. Which is unacceptable, IMHO. BTW - Is Sander still building on Red Hat Linux 6.x? Please do not resolve this as invalid, because this bug is completely valid! If you think it is invalid, say why...
I think it is invalid because the problem must be solved in the base product, namely the X headers since they are simply broken. A hint in the README for people who run into this problem would be a good thing.
If it was fixed at source then the whole statement should be removed because all platforms would not need the extern c directive. So that is not an argument for not patching this. We need to patch this because of the high rate of this error coming up.
That's exactly what i'm talking about: fix it at the source. The source is XFree which seems to have distributed incomplete headers at some time; they should stop that. Anyway this will be obsolete as soon as i can check the Xinerama stuff into extensions as we need PIC code in libXinerama.a anyway (which means we'll have to build it).
Same bug on Debian unstable (up to date) This should in my opinion be fixed *both* in OOo and XFree. (OOo should compile on as much platforms as possible ...)
It already is fixed in latest XFree. BTW - Ken, you already fixed this so this should be closed. Right?
I'd like to keep this one open until i can check in the Xinerama part of XFree that we need to compile Xinerama with -fPIC; which is currently still delayed by legal review :-(
Fundamtentally this has been committed so the code actually compiles. There is a bug raised at source for X to consider patching properly. The issue is with instreaming Xinerama to resolve this problem completely. Leaving open as suggested.
Won't be able to fix this for 1.1 -> 1.1.1
The Xinerama header has been resolved at source on the X windows cvs server. This will take some time to flow out to distributions however. The patch for inserting extern C has been applied to OOo source and there are no issue with any builds since this patch has been applied. Consider this closed.
ken: but is there also code to build a libXinerama.a containing PIC code ? This issue is still open because i want to check that in as soon as legal review for that is done.
Created attachment 8199 [details] modifications for x11_extensions to produce a PIC libXinerama.a
As the legal process to for checking in Xinerama has taken far longer than expected (and still goes on, please don't ask :-( ) i finally decided to make good on my promise that i gave Kevin a long time ago on a mailing list far, far away. I have attached a tarball that you can extract over your existing x11_extensions module; place Xinerama.h into the inc subdir and Xinerama.c into the source subdir, build, deliver and you should have a PIC libXinerama.a. I used the source and header file from XFree 4.3, this should do the trick for you, too.
I give up on this. Since nobody seems to have an urgent issue left with this i think we can live with using the Xinerama library on Intel and Sparc only. closing