Anderson Lizardo andersonlizardo@yahoo.com.br writes:
Hi,
Changelog:
Fixed the libGL.a configure check for systems where /usr/X11R6/lib/libGL.so is a symbolic link.
PS.: I've not used a simple "test -e" because http://www.winehq.org/hypermail/wine-patches/2002/01/0206.html says this does not work on Solaris.
My guess is that if test -e doesn't work, test -L won't work either...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexandre Julliard wrote:
Anderson Lizardo andersonlizardo@yahoo.com.br writes:
Fixed the libGL.a configure check for systems where /usr/X11R6/lib/libGL.so is a symbolic link.
PS.: I've not used a simple "test -e" because http://www.winehq.org/hypermail/wine-patches/2002/01/0206.html says this does not work on Solaris.
My guess is that if test -e doesn't work, test -L won't work either...
What about the attached patch? It uses "ls" instead of "test" to test for file presence (assuming ls returns non-zero code on a non-present file, which is true for a POSIX compliant system).
Snippet:
- - if test -f /usr/X11R6/lib/libGL.a -a ! -f /usr/X11R6/lib/libGL.so -a ! -f /usr/X11R6/lib/libGL.dylib + if ls /usr/X11R6/lib/libGL.a >/dev/null 2>&1 -a \ + ! ls /usr/X11R6/lib/libGL.so >/dev/null 2>&1 -a \ + ! ls /usr/X11R6/lib/libGL.dylib >/dev/null 2>&1
Best regards, - -- Anderson Lizardo
Anderson Lizardo andersonlizardo@yahoo.com.br writes:
What about the attached patch? It uses "ls" instead of "test" to test for file presence (assuming ls returns non-zero code on a non-present file, which is true for a POSIX compliant system).
It would be much better to try the actual linking and see what happens.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexandre Julliard wrote:
It would be much better to try the actual linking and see what happens.
Indeed, I was thinking on that myself... Why we just don't remove this (incorrect IMHO) file presence check and let autoconf do the check itself, which it already does as evidenced on the following snippet from configure.ac:
dnl Check for the presence of the library AC_CHECK_LIB(GL,glXCreateContext, OPENGL_LIBS="-lGL" ,, $X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS)
Additionally, looking at the commit message that added the "test -e" check:
Changelog: Check for common broken nVidia+Mesa OpenGL library setups. http://cvs.winehq.org/cvsweb/wine/Attic/configure.in.diff?r1=1.247&r2=1....
The current "test" check definitely does not ensure the system doesn't have this "broken" setup. As you said, it should be better to let autoconf do the check properly with AC_CHECK_LIB.
So here goes my latest patch which incorporates your suggestion (it just removes the broken check). I've tested it with both NVidia libraries (nvidia-glx and nvidia-glx-dev on Ubuntu 5.04) and Mesa "pure" libraries, and wine compiled with OpenGL on both setups. For tests, I've used:
make -C dlls/ddraw/tests/ test
Although I'm not sure this is the ideal test to check if OpenGL is working with Wine.
Best regards, - -- Anderson Lizardo
ons, 29,.06.2005 kl. 20.11 -0400, skrev Anderson Lizardo:
Changelog: Check for common broken nVidia+Mesa OpenGL library setups. http://cvs.winehq.org/cvsweb/wine/Attic/configure.in.diff?r1=1.247&r2=1....
The current "test" check definitely does not ensure the system doesn't have this "broken" setup. As you said, it should be better to let autoconf do the check properly with AC_CHECK_LIB.
Certainly does. The broken setup is as follows:
/usr/lib/libGL.so <- belongs to nvidia /usr/lib/libGL.a <- no such thing /usr/X11R6/lib/libGL.so <- deleted by nvidia installer /usr/X11R6/lib/libGL.a <- still exists, belongs to Mesa
Linking will succeed whatever you do, but if you don't check for this setup, Wine will be statically linked to Mesa here, and users will complain about no hardware acceleration. The AC_MSG_ERROR just puts this in terms that users understand, even though it's not an accurate message, and probably why you didn't see the point of the check.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Ove Kaaven wrote:
ons, 29,.06.2005 kl. 20.11 -0400, skrev Anderson Lizardo:
Changelog: Check for common broken nVidia+Mesa OpenGL library setups. http://cvs.winehq.org/cvsweb/wine/Attic/configure.in.diff?r1=1.247&r2=1....
The current "test" check definitely does not ensure the system doesn't have this "broken" setup. As you said, it should be better to let autoconf do the check properly with AC_CHECK_LIB.
Certainly does. The broken setup is as follows:
/usr/lib/libGL.so <- belongs to nvidia /usr/lib/libGL.a <- no such thing /usr/X11R6/lib/libGL.so <- deleted by nvidia installer /usr/X11R6/lib/libGL.a <- still exists, belongs to Mesa
Linking will succeed whatever you do, but if you don't check for this setup, Wine will be statically linked to Mesa here, and users will complain about no hardware acceleration. The AC_MSG_ERROR just puts this in terms that users understand, even though it's not an accurate message, and probably why you didn't see the point of the check.
Hi,
Based on your broken setup description, I've made a simple test case that (hopefully) correctly checks if the OpenGL setup is broken or not.
Can you run it and return the results? I've attached both the configure.ac file and the already assembled configure script (gzipped).
I would expect "OpenGL setup is OK!" on a correct setup, "OpenGL setup is broken!" on a broken one and "OpenGL support is not compilable" if OpenGL dev files are not installed.
Based on your results, I'll send the (hopefully) final patch.
Thanks, - -- Anderson Lizardo
AC_PREREQ(2.53) AC_INIT([TestCase],0.1,[none]) AC_PATH_XTRA
AC_CHECK_HEADERS(GL/gl.h GL/glx.h) if test "$ac_cv_header_GL_gl_h" = "yes" -a "$ac_cv_header_GL_glx_h" = "yes" then AC_CHECK_LIB(GL,glXCreateContext,OPENGL_LIBS="-lGL",, $X_LIBS -lXext -lX11 -lm $X_EXTRA_LIBS) if test "$ac_cv_lib_GL_glXCreateContext" = "yes" then AC_MSG_NOTICE([OpenGL setup is OK!]) else AC_MSG_ERROR([OpenGL setup is broken!]) fi else AC_MSG_NOTICE([OpenGL support is not compilable]) fi
On Tue, 28 Jun 2005, Anderson Lizardo wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexandre Julliard wrote:
Anderson Lizardo andersonlizardo@yahoo.com.br writes:
Fixed the libGL.a configure check for systems where /usr/X11R6/lib/libGL.so is a symbolic link.
PS.: I've not used a simple "test -e" because http://www.winehq.org/hypermail/wine-patches/2002/01/0206.html says this does not work on Solaris.
My guess is that if test -e doesn't work, test -L won't work either...
What about the attached patch? It uses "ls" instead of "test" to test for file presence (assuming ls returns non-zero code on a non-present file, which is true for a POSIX compliant system).
Snippet:
if test -f /usr/X11R6/lib/libGL.a -a ! -f
/usr/X11R6/lib/libGL.so -a ! -f /usr/X11R6/lib/libGL.dylib
if ls /usr/X11R6/lib/libGL.a >/dev/null 2>&1 -a \
! ls /usr/X11R6/lib/libGL.so >/dev/null 2>&1 -a \
! ls /usr/X11R6/lib/libGL.dylib >/dev/null 2>&1
Best regards,
Anderson Lizardo
On Solaris 9 and Solaris 10 the man page for test say -e checks if the file exists, and -L checks if the file exists and is a symbolic link.
-e is not avaliable in the shell sh, there is no mention if -L works or not in sh.
It might be a problem for just Solaris 8, or the tests are/were ran in the sh shell.