GNOME Bugzilla – Bug 348169
shouldn't search X libraries in prefixs other than $x_libraries
Last modified: 2006-10-24 19:14:08 UTC
gnome-mag search X libraries in prefixes other than the one specified by $x_libraries. This can be annoying, since the magnifier can find a library in a path that the user doesn't expect.
Not sure this is really a bug; without searching outside x_libraries, on some platforms gnome-mag won't build at all - some of the libs aren't included in x_libraries on those platforms. For instance, this was a problem on Solaris with XSun. On Solaris some of the client libs were (once) in /usr/sfw instead of the main X directory.
but the X libraries are searched outside x_libaries, what could be annoying. Only to illustrate it, I was writing the composite tests and how it searchs in directories that are not in x_libraries it was finded at /usr/X11R6/lib and not in the xserver that I build and passed to --x-libraries=/paht/to/my/test/libs, so the detection of XCompositeGetOverlayWindow failed, instead of be successfull. Moreover, the --x-libraries could be setted to more than one single path. The biggest problem that I saw in the way that the things are done is that the paths are hardcoded.
Created attachment 69299 [details] [review] Only search X libraries in prefixes specified by x_libraries This leave in the hands of the "configure script runner" the ability to set the paths to search for X libraries and headers. This can be setted by --x-includes and --x-libaries options in configure. More than one path can be setted using --x-includes="/path/to/dir/one /path/to/dir/two", the same applies to --x-libraries.
I think it's important to test this on older versions of XOrg and on XSun before accepting it. It would be nice to test on Fedora as well.
there are still people using xfree86 as well
do you know anyone who have these softwares installed and can test it?
I'll try and test on an older XOrg server, and get assistance building on an XSun environment. I don't know about XFree... Will Walker can test the patch on Fedora I believe.
Hi Bill, when the 2.16 be realeased can't we apply the patch? We can tag the 2.16 code, so we have a point of stable code. This way we could use the 2.17 release cycle to test it and if the community find bugs in it we can easily revert the problem. What do you think?
Hi Carlos - patch looks good, but it fails to find DAMAGE extension on Ubuntu Dapper (6.06). If we can fix that then I believe we should go ahead and commit to CVS (after branching for gnome-2.16 as you suggest). Thanks again! ====== snipped from config.log ==== ... configure:22615: checking for XDamageCreate in -lXdamage configure:22645: gcc -o conftest -g -O2 -Wall conftest.c -lXdamage >&5 /usr/bin/ld: cannot find -lXdamage collect2: ld returned 1 exit status configure:22651: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE "gnome-mag" | #define VERSION "0.13.1" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define GETTEXT_PACKAGE "gnome-mag" | #define HAVE_LOCALE_H 1 | #define HAVE_LC_MESSAGES 1 | #define HAVE_BIND_TEXTDOMAIN_CODESET 1 | #define HAVE_GETTEXT 1 | #define HAVE_DCGETTEXT 1 | #define ENABLE_NLS 1 | /* end confdefs.h. */ | | /* Override any gcc2 internal prototype to avoid an error. */ | #ifdef __cplusplus | extern "C" | #endif | /* We use char because int might match the return type of a gcc2 | builtin and then its argument prototype would still apply. */ | char XDamageCreate (); | int | main () | { | XDamageCreate (); | ; | return 0; | } configure:22676: result: no configure:22689: checking for -lXdamage in /usr/X11R6/lib configure:22707: gcc -o conftest -g -O2 -Wall conftest.c -L/usr/X11R6/lib -lXdamage -lX11 >&5 conftest.c: In function 'main': conftest.c:36: warning: implicit declaration of function 'XDamageCreate' /usr/bin/ld: cannot find -lXdamage collect2: ld returned 1 exit status configure:22713: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "" | #define PACKAGE_TARNAME "" | #define PACKAGE_VERSION "" | #define PACKAGE_STRING "" | #define PACKAGE_BUGREPORT "" | #define PACKAGE "gnome-mag" | #define VERSION "0.13.1" | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_STRINGS_H 1 | #define HAVE_INTTYPES_H 1 | #define HAVE_STDINT_H 1 | #define HAVE_UNISTD_H 1 | #define HAVE_DLFCN_H 1 | #ifdef __cplusplus | extern "C" void std::exit (int) throw (); using std::exit; | #endif | #define GETTEXT_PACKAGE "gnome-mag" | #define HAVE_LOCALE_H 1 | #define HAVE_LC_MESSAGES 1 | #define HAVE_BIND_TEXTDOMAIN_CODESET 1 | #define HAVE_GETTEXT 1 | #define HAVE_DCGETTEXT 1 | #define ENABLE_NLS 1 | /* end confdefs.h. */ | | int | main () | { | XDamageCreate() | ; | return 0; | } configure:22737: result: no configure:22744: WARNING: Couldn't find the DAMAGE library. Check config.log for details
Hi Bill - The default installation of Ubuntu does not ship development libraries so you must install the libxdamage-dev package. This also happening to me the first time I installed Ubuntu here. I don't know if you need to install any other package, btw, you can install the xorg-dev package that install all the development libraries/header to develop X applications.
Ah, yes of course! Please commit the patch after tagging CVS. I suggest we patch later if we encounter problems on old platforms that can't be solved by using --x-libraries and --x-includes. Bill
I don't understand what you want to mean with patch later. Patch what?
Fixed in the development version. The fix will be available in the next major release. Thank you for your bug report. The old revision of configure.in before the commit was 1.113. Moreover the code was also branched, so before the commit a new branch, gnome-2-16, was created.