I am able to compile almost all packages for xfce 4.6.0 except for xfce4-settings-4.6.0 .. when compiling it complains about xi.pc and x11.pc .. I'm running on redhat 4 which is only X11R6 release. I believe xi.pc and x11.pc are requirements for X11R7? I made a "fake" xi.pc and x11.pc and I see these errors: xfce4_mouse_settings-main.o(.text+0x690): In function `mouse_settings_device_selection_changed': /home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:608: undefined reference to `XOpenDevice' xfce4_mouse_settings-main.o(.text+0x6bb):/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:616: undefined reference to `XGetDeviceButtonMapping' xfce4_mouse_settings-main.o(.text+0x71e):/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:635: undefined reference to `XGetFeedbackControl' xfce4_mouse_settings-main.o(.text+0x75a):/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:661: undefined reference to `XCloseDevice' xfce4_mouse_settings-main.o(.text+0xefd): In function `main': /home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:1226: undefined reference to `XGetExtensionVersion' xfce4_mouse_settings-main.o(.text+0x102b):/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:893: undefined reference to `XListInputDevices' xfce4_mouse_settings-main.o(.text+0x134a):/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings/main.c:974: undefined reference to `XFreeDeviceList' collect2: ld returned 1 exit status make[4]: *** [xfce4-mouse-settings] Error 1 make[4]: Leaving directory `/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs/mouse-settings' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0/dialogs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/mc7/xfce64-4.6.0/xfce4-settings-4.6.0' make: *** [all] Error 2 Conversation from IRC: <sarts> it is a problem <networked> err i dont mind submitting one, just want to make sure it's not my problem first <sarts> ah, sure. <sarts> but, X11R7 is not the desired minimally required version <sarts> so... if thats the case, it needs to be fixored <networked> sarts, ahh great news.. what is the minimal? <sarts> x11r6, glib-2.12, gtk-2.10, dbus, and optional xrandr. <networked> cool then redhat 4 should meet those requirements (I also compiled my own newer glib+gtk) <networked> redhat4 = x11r6
Yeah, we should fall back to the crappy old annoying method of trying to find libs manually in /usr/X11R6 and stuff. Sigh. Should just copy the configure checks from xfce-mcs-plugins.
I'm against this. We using some relative new api (I doubt it's newer then the gtk release we use), why adding all the configure crap again for people compiling bleeding edge software on a 10+ year (?) old distribution. Seriously, we're moving forward here, not moving backwards for a hand full of people.
Uh, xorg 7.0 was released on 21 December 2005. That's only slightly more than 3 years ago. Reporter is running RHEL4. That's not particularly old either. We should at least give it a shot...
Well IIRC the module dependency checks gave some problems too on _some_ systems too (recent ones). Maybe we can create some sort of fallback system that checks for the libraries/headers if the .pc file is not found (ie. when XDT_CHECK_PACKAGE found nothing), I can agree on that, but completely dropping the package detection and switching back to the old way is a no-go for me.
(In reply to comment #4) > Maybe we can create some sort of fallback system that checks for the > libraries/headers if the .pc file is not found (ie. when XDT_CHECK_PACKAGE > found nothing), I can agree on that, Uh, yeah, that's exactly what I was intending. Patch forthcoming.
Created attachment 2211 fall back to manual lib search Not sure if this works, but it's a start.
Yeah something like that should work. Maybe take a look at gnome-settings-daemon, they made a small macro AC_CHECK_X_LIB: http://svn.gnome.org/svn/gnome-settings-daemon/trunk/configure.ac
Hmm yeah, that's good. Should probably look at our XDT_CHECK_LIBX11 macro and see if there's anything useful in the search bit to add, and then add an ability to check for specific libs that way. I'll try to see if I can work on this tonight or tomorrow.
Ok, never really got around to this, obviously. I added the fallback libXi check to svn trunk. Someone on a system that needs this should give it a try and see if it works, then I'll backport it back to the 4.6 branch.
(In reply to comment #9) > Ok, never really got around to this, obviously. I added the fallback libXi > check to svn trunk. Someone on a system that needs this should give it a try > and see if it works, then I'll backport it back to the 4.6 branch. The same problem is seen on Solaris, which has neither xi.pc nor x11.pc (and I can't find them on a current OpenSolaris release either). I tried the patch on Solaris and it doesn't help. There are two problems: The fix needs to be applied for both libXi and libX11 On Solaris, the libraries are in /usr/openwin (or just /usr) which isn't searched for.
Why do we have custom stuff for finding the X11 libs anyway? What's wrong with the autoconf builtins AC_PATH_X or even better AC_PATH_XTRA? (See http://www.gnu.org/software/autoconf/manual/autoconf.html#System-Services)
Because we use some newish api, beter fail at configure. Personally I think we should not spend any time on this, we depend on gtk 2.10 which was released on juli 2006, xorg r7 on december 2005 and xfce 4.6 this year. If we want to move forward it's not too mich to ask to have a dependency that's already there for a few years right? If Solaris and other desktops want to use the old 9.x xorg, fine by me, but don't bother us if it doesn't work, use Xfce 4.4 instead. If we do want to support the crap old stuff, make x11 and xi optional dependencies and simply build a package without support for pointers, keyboard etc.
We are running redhat 4 enterprise... It would be nice to offer 4.6.X to our users as an option... We would like to move to redhat 5 which has newer xlibs and such but we're not there yet.. We like xfce and what it has to offer, but if you no longer want to support older x releases then thats a decision your team needs to make. Please let me know if you can implement 4.6.x on redhat 4 enterprise systems, if your team isn't willing then I guess close the ticket out. We love using xfce since it's light weight and fast and works on older systems. Please let me know if you can come to a decision soon. thanks, Mike
Mike: have you tried the attached patch? A fix for this is waiting on someone to test it.
Brian, sorry, will test it this week or by early next week and will get back to you.. Just wondering 1) how do I apply patch 2) what directory should I run this patch in thanks, Mike
http://www.google.com/#q=how+to+apply+a+source+code+patch
brian, would it be possible to get patch for 4.6.1 .. I redownloaded the latest source bundle.. I'm assuming I would run this: patch -p0 <../../patch in xfce-4.6.1/xfce4-settings-4.6.1 thanks, Mike
I have a system ready to test with now with the 4.6.1 src package of xfce.. Do you only want me to test with 4.6.0 or could you supply a patch for 4.6.1 ? thanks, Mike
i did the following: in /xfce4-settings-4.6.1 patch <patch It prompted me for a file so I typed in: configure.ac then I ran: autoconf and then reran ./configure and this is the output: checking LIBWNCK_LIBS... -L/opt/xfce-4.6.1/lib -lwnck-1 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for xi >= 1.0.0... not found checking for XListInputDevices in -lXi... no checking for XListInputDevices in -lXi... (cached) no checking for XListInputDevices in -lXi... (cached) no checking for XListInputDevices in -lXi... (cached) no *** The required package Xi was not found on your system. *** Please install Xi or adjust the PKG_CONFIG_PATH environment *** variable if you installed the package in a nonstandard *** prefix so that pkg-config is able to find it. Any other ideas or is this just not going to work on older X systems? thanks, Mike
Where is your copy of 'libXi.so'? When you find it, change to that directory and run the command "strings libXi.so | grep XListInputDevices", and paste the output here. Though I suspect there's a problem with the check... stupid cache.
libXi.so is in 2 places since this is a 64 bit system, but they both contain it and I'm compiling 64 bit so.. [mc7@dcflnxdev02:/usr/X11R6/lib64$]: strings libXi.so | grep XListInputDevices XListInputDevices Looks like it has it.. thanks, Mike
changed line 97 in configure.ac to: LIBS="$LIBS -L$dir/lib64" and changed line 101 to: XI_LIBS="-L$dir/lib64 -lXi" reran autoconf and it seemed to compile fine.. Is there a way to make it check for 64 bit libs? Guess your change and this one above would make it work on older releases of X11, specially X11R6 on 64 bit redhat enterprise linux. Could all this be included in the next release? I would be willing to test an entirely new source package and try to compile it (without making edits). thanks, Mike
Don't you have the usual lib -> lib64 symlinks? I guess it wouldn't hurt to check for the lib64 variant at the end, though.
Again, this is redhat 4 update 8 64 bit.. Looks like the 2 directories are completely separate.. I guess lib is 32 bit only and 64 is 64 bit only.. I didn't set it up like this.. this is the default on this OS. Would it be possible to add everything and get it in 4.6.2? :) [mc7@dcflnxdev02:/usr/X11R6/lib$]: ls -la *Xi* -rw-r--r-- 1 root root 60460 Mar 31 2009 libXi.a -rw-r--r-- 1 root root 4722 Mar 31 2009 libXinerama.a lrwxrwxrwx 1 root root 18 Sep 25 04:16 libXinerama.so -> libXinerama.so.1.0 lrwxrwxrwx 1 root root 18 Sep 25 04:11 libXinerama.so.1 -> libXinerama.so.1.0 -rwxr-xr-x 1 root root 7840 Mar 31 2009 libXinerama.so.1.0 lrwxrwxrwx 1 root root 12 Sep 25 04:16 libXi.so -> libXi.so.6.0 lrwxrwxrwx 1 root root 12 Sep 25 04:11 libXi.so.6 -> libXi.so.6.0 -rwxr-xr-x 1 root root 28828 Mar 31 2009 libXi.so.6.0 [mc7@dcflnxdev02:/usr/X11R6/lib$]: cd .. [mc7@dcflnxdev02:/usr/X11R6$]: cd lib64 [mc7@dcflnxdev02:/usr/X11R6/lib64$]: ls -la *Xi* -rw-r--r-- 1 root root 92640 Mar 31 2009 libXi.a -rw-r--r-- 1 root root 7414 Mar 31 2009 libXinerama.a lrwxrwxrwx 1 root root 18 Sep 25 04:16 libXinerama.so -> libXinerama.so.1.0 lrwxrwxrwx 1 root root 18 Sep 25 04:11 libXinerama.so.1 -> libXinerama.so.1.0 -rwxr-xr-x 1 root root 11280 Mar 31 2009 libXinerama.so.1.0 lrwxrwxrwx 1 root root 12 Sep 25 04:16 libXi.so -> libXi.so.6.0 lrwxrwxrwx 1 root root 12 Sep 25 04:11 libXi.so.6 -> libXi.so.6.0 -rwxr-xr-x 1 root root 35880 Mar 31 2009 libXi.so.6.0
So just wondering if both changes can be implemented? 1) the patch provided here 2) adding on the lib64 path check? these 2 things make the xfce-settings package compile on rhel 4 just fine... no other packages fail.. Any word on when 4.6.2 would be released and could this be included? thanks, Mike