Re: [patch]: detecting gdk-imlib11 by configure
Hi folks,
Sorry for the delay.
seventh guardian wrote:
On 9/4/06, Dominik Vogt [EMAIL PROTECTED] wrote:
If we really do not use implib I'm all for removing the
test. It's causing endless troubles for me.
Ok, done.
It's strange, but it seems that the imlib test macro was realy never
used! So it's strange how it affected the compilation under Debian..
Harald does it work now?
Yes, configure went fine:
FVWM Configuration:
Version: 2.5.18 (from cvs)
Executables: /usr/local/bin
Man pages: /usr/local/share/man
Modules: /usr/local/libexec/fvwm/2.5.18
Data files: ${prefix}/share/fvwm
Perl lib:${prefix}/share/fvwm/perllib
Locale msg: ${prefix}/share/locale ar de fr sv_SE zh_CN
With Asian bi-direct. text support? yes
With Gettext Native Lang support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? yes
With GNOME libs support in FvwmGtk? yes
With Iconv support? yes (from C library)
With Mouse strokes (gestures)? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent?yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support?yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
I also tried --with-gnome=no and --disable-gtk. Nothing
unexpected.
Many thanx
Harri
signature.asc
Description: OpenPGP digital signature
Re: [patch]: detecting gdk-imlib11 by configure
On 9/4/06, Harald Dunkel [EMAIL PROTECTED] wrote: seventh guardian wrote: I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Since no part of fvwm (except for acinclude.m4) makes use of imlib-dev, would it be OK to remove the tests for imlib-dev in acinclude.m4 (afap), and keep just the tests for gdk-imlib-dev? Just to reduce the number of lines of code to cleanup? Its not that simple, acinclude is a bunch of functions included by configure.ac. Both files would need to be revised. But the idea is correct: to remove the tests for imlib and cleanup the ones for gdk-imlib. Any second opinions about this? Cheers Renato Regards Harri
Re: [patch]: detecting gdk-imlib11 by configure
On 9/4/06, Dominik Vogt [EMAIL PROTECTED] wrote: On 9/4/06, Harald Dunkel [EMAIL PROTECTED] wrote: seventh guardian wrote: I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Since no part of fvwm (except for acinclude.m4) makes use of imlib-dev, would it be OK to remove the tests for imlib-dev in acinclude.m4 (afap), and keep just the tests for gdk-imlib-dev? Just to reduce the number of lines of code to cleanup? Its not that simple, acinclude is a bunch of functions included by configure.ac. Both files would need to be revised. But the idea is correct: to remove the tests for imlib and cleanup the ones for gdk-imlib. Any second opinions about this? If we really do not use implib I'm all for removing the test. It's causing endless troubles for me. Ok, done. It's strange, but it seems that the imlib test macro was realy never used! So it's strange how it affected the compilation under Debian.. Harald does it work now? Cheers Renato Ciao Dominik ^_^ ^_^ -- Feel free – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
Re: [patch]: detecting gdk-imlib11 by configure
On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote:
Hi folks,
Of course I haven't tried all different Linux distros. but
for Debian Etch I have to apply the appended patch to make
detecting gdk-imlib11 work. imlib11 (without gdk-)
does not seem to be necessary. Imlib.h doesn't appear
anywhere in the code, except for acinclude.m4.
You are changing what I believe is the test for Imlib. There is
already a test for gdk_imlib bellow (which also includes gdk_imlib.h),
but I don't know why it doesn't work for you..
Is this patch OK? Could somebody please verify and apply?
Of course the patched fvwm built cleanly (at least on my
Debian box).
I think you are doing the wrong thing, as you are tricking the
system to inclue gdk_imlib when it detects plain imlib. You should try
to figure out why it isn't detecting gdk_imlib..
Cheers
Renato
Many thanx
Harri
Before:
FVWM Configuration:
Version: 2.5.18 (from cvs)
Executables: /usr/local/bin
Man pages: /usr/local/man
Modules: /usr/local/libexec/fvwm/2.5.18
Data files: /usr/local/share/fvwm
Perl lib:/usr/local/share/fvwm/perllib
Locale msg: /usr/local/share/locale ar de fr sv_SE zh_CN
With Asian bi-direct. text support? yes
With Gettext Native Lang support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? no: Failed on gdk-imlib, see config.log
With GNOME libs support in FvwmGtk? yes
With Iconv support? yes (from C library)
With Mouse strokes (gestures)? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent?yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support?yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
After:
FVWM Configuration:
Version: 2.5.18 (from cvs)
Executables: /usr/local/bin
Man pages: /usr/local/share/man
Modules: /usr/local/libexec/fvwm/2.5.18
Data files: ${prefix}/share/fvwm
Perl lib:${prefix}/share/fvwm/perllib
Locale msg: ${prefix}/share/locale ar de fr sv_SE zh_CN
With Asian bi-direct. text support? yes
With Gettext Native Lang support? yes (libc)
With GTK+ required for FvwmGtk? yes
With GDK image support in FvwmGtk? yes
With GNOME libs support in FvwmGtk? yes
With Iconv support? yes (from C library)
With Mouse strokes (gestures)? yes
With PNG image support? yes
With ReadLine sup. in FvwmConsole? yes
With RPlay support in FvwmEvent?yes
With Shaped window support? yes
With Shared memory for XImage? yes
With Session Management support?yes
With Xinerama multi-head support? yes
With Xft anti-alias font support? yes (version 2)
With XPM image support? yes
With Xrender image support? yes
Index: acinclude.m4
===
RCS file: /home/cvs/fvwm/fvwm/acinclude.m4,v
retrieving revision 1.54
diff -u -u -r1.54 acinclude.m4
--- acinclude.m42 Mar 2006 11:38:35 - 1.54
+++ acinclude.m43 Sep 2006 14:25:08 -
@@ -589,7 +589,7 @@
AC_TRY_RUN([
#include stdio.h
#include stdlib.h
-#include Imlib.h
+#include gdk_imlib.h
ImlibImage testimage;
@@ -648,7 +648,7 @@
LIBS=$LIBS $IMLIB_LIBS
AC_TRY_LINK([
#include stdio.h
-#include Imlib.h
+#include gdk_imlib.h
], [ return 0; ],
[ echo *** The test program compiled, but did not run. This usually
means
echo *** that the run-time linker is not finding IMLIB or finding the
wrong
@@ -728,7 +728,6 @@
AC_TRY_RUN([
#include stdio.h
#include stdlib.h
-#include Imlib.h
#include gdk_imlib.h
/* migo: originally it was GdkImLibColor with incorrect spelling */
@@ -794,7 +793,6 @@
LIBS=$LIBS $GDK_IMLIB_LIBS
AC_TRY_LINK([
#include stdio.h
-#include Imlib.h
#include gdk_imlib.h
], [ return 0; ],
[ (echo *** The test program compiled, but did not run. This usually
means 5) 2/dev/null || \
Index: ChangeLog
===
RCS file: /home/cvs/fvwm/fvwm/ChangeLog,v
retrieving revision 1.2756
diff -u -u -r1.2756 ChangeLog
--- ChangeLog 31 Aug 2006 11:36:56 - 1.2756
+++ ChangeLog 3 Sep 2006 14:25:31 -
@@ -1,3 +1,8 @@
+2006-09-03 Harald Dunkel [EMAIL PROTECTED]
+
+ * acinclude.m4:
+ drop obsolete dependency upon Imlib.h
+
2006-08-31 Dominik Vogt dominik(dot)vogt(at)gmx(dot)de
* fvwm/ewmh.c (atom_get):
Re: [patch]: detecting gdk-imlib11 by configure
Hi Renato, seventh guardian wrote: On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi folks, Of course I haven't tried all different Linux distros. but for Debian Etch I have to apply the appended patch to make detecting gdk-imlib11 work. imlib11 (without gdk-) does not seem to be necessary. Imlib.h doesn't appear anywhere in the code, except for acinclude.m4. You are changing what I believe is the test for Imlib. There is already a test for gdk_imlib bellow (which also includes gdk_imlib.h), but I don't know why it doesn't work for you.. On Debian (and Ubuntu?) imlib-dev and gdk-imlib-dev are seperate packages, built from the same source package. They do not rely upon each other, AFAICS. Same goes for the packages providing the runtime libraries. AFAICS fvwm doesn't make use of imlib, but of gdk-imlib. For building and running fvwm you just need gdk-imlib-dev and gdk-imlib. But to make the tests in the unpatched acinclude.m4 succeed you have to install both gdk-imlib-dev and imlib-dev, plus the appropriate runtime library packages. IMHO this is not correct. Is this patch OK? Could somebody please verify and apply? Of course the patched fvwm built cleanly (at least on my Debian box). I think you are doing the wrong thing, as you are tricking the system to inclue gdk_imlib when it detects plain imlib. You should try to figure out why it isn't detecting gdk_imlib.. The patched acinclude.m4 _does_ detect gdk-imlib. Imlib (without gdk-) is not installed on my PC, and yet I can build and run fvwm including all features, as shown in a previous post in this thread. % ldd /usr/lib/fvwm/2.5.18/FvwmGtk libSM.so.6 = /usr/lib/libSM.so.6 (0x2ae71a6d7000) libICE.so.6 = /usr/lib/libICE.so.6 (0x2ae71a7e1000) libXext.so.6 = /usr/lib/libXext.so.6 (0x2ae71a8fd000) libX11.so.6 = /usr/lib/libX11.so.6 (0x2ae71aa0e000) libm.so.6 = /lib/libm.so.6 (0x2ae71abe9000) libgtk-1.2.so.0 = /usr/lib/libgtk-1.2.so.0 (0x2ae71ad6d000) libgdk-1.2.so.0 = /usr/lib/libgdk-1.2.so.0 (0x2ae71afd3000) libgmodule-1.2.so.0 = /usr/lib/libgmodule-1.2.so.0 (0x2ae71b111000) libglib-1.2.so.0 = /usr/lib/libglib-1.2.so.0 (0x2ae71b215000) libdl.so.2 = /lib/libdl.so.2 (0x2ae71b34) libXi.so.6 = /usr/lib/libXi.so.6 (0x2ae71b443000) libgdk_imlib.so.2 = /usr/lib/libgdk_imlib.so.2 (0x2ae71b54c000) libc.so.6 = /lib/libc.so.6 (0x2ae71b671000) libXau.so.6 = /usr/lib/libXau.so.6 (0x2ae71b8ad000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x2ae71b9b) /lib64/ld-linux-x86-64.so.2 (0x2ae71a5bf000) % dpkg-query -S libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2.0.0 Regards Harri signature.asc Description: OpenPGP digital signature
Re: [patch]: detecting gdk-imlib11 by configure
On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi Renato, seventh guardian wrote: On 9/3/06, Harald Dunkel [EMAIL PROTECTED] wrote: Hi folks, Of course I haven't tried all different Linux distros. but for Debian Etch I have to apply the appended patch to make detecting gdk-imlib11 work. imlib11 (without gdk-) does not seem to be necessary. Imlib.h doesn't appear anywhere in the code, except for acinclude.m4. You are changing what I believe is the test for Imlib. There is already a test for gdk_imlib bellow (which also includes gdk_imlib.h), but I don't know why it doesn't work for you.. On Debian (and Ubuntu?) imlib-dev and gdk-imlib-dev are seperate packages, built from the same source package. They do not rely upon each other, AFAICS. Same goes for the packages providing the runtime libraries. AFAICS fvwm doesn't make use of imlib, but of gdk-imlib. For building and running fvwm you just need gdk-imlib-dev and gdk-imlib. But to make the tests in the unpatched acinclude.m4 succeed you have to install both gdk-imlib-dev and imlib-dev, plus the appropriate runtime library packages. IMHO this is not correct. Is this patch OK? Could somebody please verify and apply? Of course the patched fvwm built cleanly (at least on my Debian box). I think you are doing the wrong thing, as you are tricking the system to inclue gdk_imlib when it detects plain imlib. You should try to figure out why it isn't detecting gdk_imlib.. The patched acinclude.m4 _does_ detect gdk-imlib. Imlib (without gdk-) is not installed on my PC, and yet I can build and run fvwm including all features, as shown in a previous post in this thread. I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Cheers Renato % ldd /usr/lib/fvwm/2.5.18/FvwmGtk libSM.so.6 = /usr/lib/libSM.so.6 (0x2ae71a6d7000) libICE.so.6 = /usr/lib/libICE.so.6 (0x2ae71a7e1000) libXext.so.6 = /usr/lib/libXext.so.6 (0x2ae71a8fd000) libX11.so.6 = /usr/lib/libX11.so.6 (0x2ae71aa0e000) libm.so.6 = /lib/libm.so.6 (0x2ae71abe9000) libgtk-1.2.so.0 = /usr/lib/libgtk-1.2.so.0 (0x2ae71ad6d000) libgdk-1.2.so.0 = /usr/lib/libgdk-1.2.so.0 (0x2ae71afd3000) libgmodule-1.2.so.0 = /usr/lib/libgmodule-1.2.so.0 (0x2ae71b111000) libglib-1.2.so.0 = /usr/lib/libglib-1.2.so.0 (0x2ae71b215000) libdl.so.2 = /lib/libdl.so.2 (0x2ae71b34) libXi.so.6 = /usr/lib/libXi.so.6 (0x2ae71b443000) libgdk_imlib.so.2 = /usr/lib/libgdk_imlib.so.2 (0x2ae71b54c000) libc.so.6 = /lib/libc.so.6 (0x2ae71b671000) libXau.so.6 = /usr/lib/libXau.so.6 (0x2ae71b8ad000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x2ae71b9b) /lib64/ld-linux-x86-64.so.2 (0x2ae71a5bf000) % dpkg-query -S libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2 gdk-imlib11: /usr/lib/libgdk_imlib.so.2.0.0 Regards Harri
Re: [patch]: detecting gdk-imlib11 by configure
seventh guardian wrote: I see your point, and I agree that things may not be working correctly. But what you did is a hack. You just changed the test program to detect imlib when it is not there. Even if it works that way, it should be done properly. Probably a cleanup would be good.. There's a bunch of dup/unused code in that file.. Since no part of fvwm (except for acinclude.m4) makes use of imlib-dev, would it be OK to remove the tests for imlib-dev in acinclude.m4 (afap), and keep just the tests for gdk-imlib-dev? Just to reduce the number of lines of code to cleanup? Regards Harri signature.asc Description: OpenPGP digital signature
