Re: [PATCH] gui/configure.ac -- wrong inclusion paths
On Friday, February 27, 2004, at 10:45 PM, Kazunobu Kuriyama wrote: No test should use these to look for a library or include, it's only used for collecting all the include flags that should go in config.make I see. Now I don't see any problem with your patch. I'd appreciate it if you could commit it soon. Done. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac -- wrong inclusion paths
Adam Fedor wrote: On Friday, February 27, 2004, at 09:51 PM, Kazunobu Kuriyama wrote: But the part @@ -172,9 +172,6 @@ AC_MSG_ERROR(gnustep-gui will not compile without tiff) fi -ADDITIONAL_INCLUDE_DIRS="ADDITIONAL_INCLUDE_DIRS $GRAPHIC_CFLAGS" -ADDITIONAL_LIB_DIRS="ADDITIONAL_LIB_DIRS $GRAPHIC_LFLAGS" is not the one I added recently, so I'm not completely sure we can safely remove these two lines. IMO, they are redundant for checking the audiofile stuff, but appear they were put there in order to enable us to check the png stuff in a more elaborated way in future when we need such a elaboration (e.g. detection of .a/.so/.h files installed in non-standard locations). I didn't remove the lines, I just moved them to the end of configure.ac. No, you didn't. My English was misleading. :) No test should use these to look for a library or include, it's only used for collecting all the include flags that should go in config.make I see. Now I don't see any problem with your patch. I'd appreciate it if you could commit it soon. Thanks, - Kazunobu Kuriyama ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac -- wrong inclusion paths
On Friday, February 27, 2004, at 09:51 PM, Kazunobu Kuriyama wrote: But the part @@ -172,9 +172,6 @@ AC_MSG_ERROR(gnustep-gui will not compile without tiff) fi -ADDITIONAL_INCLUDE_DIRS="ADDITIONAL_INCLUDE_DIRS $GRAPHIC_CFLAGS" -ADDITIONAL_LIB_DIRS="ADDITIONAL_LIB_DIRS $GRAPHIC_LFLAGS" is not the one I added recently, so I'm not completely sure we can safely remove these two lines. IMO, they are redundant for checking the audiofile stuff, but appear they were put there in order to enable us to check the png stuff in a more elaborated way in future when we need such a elaboration (e.g. detection of .a/.so/.h files installed in non-standard locations). I didn't remove the lines, I just moved them to the end of configure.ac. No test should use these to look for a library or include, it's only used for collecting all the include flags that should go in config.make ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac -- wrong inclusion paths
Adam Fedor wrote: On Tuesday, February 17, 2004, at 11:00 PM, Kazunobu Kuriyama wrote: Hi, Due to the wrong order of the inclusion paths set by configure.ac, cpp first includes the gui's header files in $(GNUSTEP_SYSTEM_ROOT), not in the source tree. This may cause a compilation failure if a header file installed there is not consistent with the one coming with the source. CPPFLAGS shouldn't be included in the final output of configure anyway, it's just there for use of configure. This problem seems like it is due to the recent check for X. Can you see if this patch fixes it instead: I confirmed your patch fixes it. But the part @@ -172,9 +172,6 @@ AC_MSG_ERROR(gnustep-gui will not compile without tiff) fi -ADDITIONAL_INCLUDE_DIRS="ADDITIONAL_INCLUDE_DIRS $GRAPHIC_CFLAGS" -ADDITIONAL_LIB_DIRS="ADDITIONAL_LIB_DIRS $GRAPHIC_LFLAGS" is not the one I added recently, so I'm not completely sure we can safely remove these two lines. IMO, they are redundant for checking the audiofile stuff, but appear they were put there in order to enable us to check the png stuff in a more elaborated way in future when we need such a elaboration (e.g. detection of .a/.so/.h files installed in non-standard locations). Regards, - Kazunobu Kuriyama ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac -- wrong inclusion paths
On Tuesday, February 17, 2004, at 11:00 PM, Kazunobu Kuriyama wrote: Hi, Due to the wrong order of the inclusion paths set by configure.ac, cpp first includes the gui's header files in $(GNUSTEP_SYSTEM_ROOT), not in the source tree. This may cause a compilation failure if a header file installed there is not consistent with the one coming with the source. CPPFLAGS shouldn't be included in the final output of configure anyway, it's just there for use of configure. This problem seems like it is due to the recent check for X. Can you see if this patch fixes it instead: guiconf.patch Description: Binary data ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac
Kazunobu Kuriyama wrote: [snip] > > Can you modify the patch so that it runs the libungif test > > without any special flags first, and only if the first test fails does > > it try with the X flags? > > Sure. Here is the patch rewritten for fulfilling your requirement. Thanks! It looks ok, and I assume that it works on your system. :) I'll test here (where libungif doesn't require X) and commit it tomorrow. - Alexander Malmberg ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac
Alexander Malmberg wrote:
[snip]
Anyway, -gui should definitely not link with X unless it is actually
necessary.
Indeed. That's why I suspected the "malfunction" is deliberate.
I didn't understand why config.log indicated the failure is due to
the missing symbols of X11, which is 'should definitely not'.
Can you modify the patch so that it runs the libungif test
without any special flags first, and only if the first test fails does
it try with the X flags?
Sure. Here is the patch rewritten for fulfilling your requirement.
If --with-x=no, then it never tries to get X stuff included in the
flags even if --disable-ungif=no, or --enable-ungif. The X stuff is
included only if they are actually needed to support ungif.
- Kazunobu Kuriyama
Index: configure.ac
===
RCS file: /cvsroot/gnustep/gnustep/core/gui/configure.ac,v
retrieving revision 1.16
diff -u -r1.16 configure.ac
--- configure.ac8 Jan 2004 18:43:49 - 1.16
+++ configure.ac6 Feb 2004 01:25:59 -
@@ -54,6 +54,10 @@
LDFLAGS="$LDFLAGS -Wl,-R/usr/pkg/lib -L/usr/pkg/lib";;
esac
+AC_PATH_X # Added for checking the existence of ungif. Note that
+# -gui uses the API of the underlying window system ONLY IF
+ # it is definitely necessary.
+
#
# The following is so that headers and custom libraries
# in the GNUstep root are used before the standard ones
@@ -191,7 +195,60 @@
fi
fi
-AC_CHECK_LIB(ungif, DGifOpen)
+
+AC_ARG_ENABLE(ungif,
+ [ --disable-ungif Disable UNGIF support],,
+ enable_ungif=yes)
+
+AC_ARG_WITH(ungif_library,
+ [ --with-ungif-library=DIR UNGIF library file are in DIR], ,
+ with_ungif_library=)
+AC_ARG_WITH(ungif_include,
+ [ --with-ungif-include=DIR UNGIF include files are in DIR], ,
+with_ungif_include=)
+
+if test "${enable_ungif}" = yes; then
+ orig_CPPFLAGS="${CPPFLAGS}"
+ orig_LDFLAGS="${LDFLAGS}"
+ orig_LIBS="${LIBS}"
+
+ if test -n "${with_ungif_library}"; then
+with_ungif_library="-L$with_ungif_library"
+ fi
+ if test -n "${with_ungif_include}"; then
+with_ungif_include="-I$with_ungif_include"
+ fi
+ CPPFLAGS="${with_ungif_include} ${CPPFLAGS}"
+ LDFLAGS="${with_ungif_library} ${LDFLAGS}"
+
+ AC_CHECK_LIB(ungif, DGifOpen)
+
+ if test "${with_x}" != no && test "${ac_cv_lib_ungif_DGifOpen}" = no; then
+AC_MSG_NOTICE([Checking if ungif is linked against -lX11])
+# This implies either that ungif is not installed at all, or that it
+# explicitly refers to the symbols defined in X11. Now see if the latter
+# is the case.
+CPPFLAGS="${CPPFLAGS} -I${ac_x_includes}"
+LDFLAGS="${LDFLAGS} -L${ac_x_libraries}"
+LIBS="${LIBS} -lX11"
+
+AC_CHECK_LIB(ungif, DGifCloseFile)
+if test "${ac_cv_lib_ungif_DGifCloseFile}" = no; then
+ # This indicates ungif is not installed at all. The flags reverts to
+ # the orignal value.
+ CPPFLAGS="${orig_CPPFLAGS}"
+ LDFLAGS="${orig_LDFLAGS}"
+ LIBS="${orig_LIBS}"
+else
+ # This indicates ungif actually refers to the X11's symbols. We modify
+ # the flags so that -gui gets linked against the X11 library to support
+ # ungif.
+ AC_MSG_NOTICE([-gui will be linked against -lX11 to support ungif images])
+ ADDITIONAL_INCLUDE_DIRS="$ADDITIONAL_INCLUDE_DIRS $CPPFLAGS"
+ ADDITIONAL_LIB_DIRS="$ADDITIONAL_LIB_DIRS $LDFLAGS -lX11"
+fi
+ fi
+fi
#
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] gui/configure.ac
Kazunobu Kuriyama wrote: > Since the ungif library refers to some symbols defined in the X11 > library, we need some flags such as -I/usr/X11R6/include and > -L/usr/X11R6/lib -lX11 when building -gui with ungif. > > However, configure.ac is not written to accomplish it. As a result, > it cannot detect the existence of ungif correctly, and thus the > resulting -gui won't support ungif images. > > Hopefully, the attached patch rectifies this. This was deliberate. libungif can be configured in a way that causes it to link with X, but this seems like a mixup on libungif's part (using the same LDFLAGS for the library and the example image viewer). Hopefully, they will fix this. Presumably, distributions already deal with this since those I asked to check this said that libungif on their systems didn't link with X. Anyway, -gui should definitely not link with X unless it is actually necessary. Can you modify the patch so that it runs the libungif test without any special flags first, and only if the first test fails does it try with the X flags? Ie. something like: AC_CHECK_LIB(ungif, DGifOpen) if test "$ac_cv_lib_ungif_DGifOpen" = no; then # On some systems, libungif refers to symbols defined in the X11 library. # Thus, if the test failed, we try again to see if libungif works when we # link with libX11. [insert test linked with X11 here] fi It's possible that autoconf will be clever and cache the test result. If so, the second AC_CHECK_LIB could use DGifCloseFile instead of DGifOpen. Also, hardcoding a path to X isn't right. IIRC, autoconf includes a macro for checking for X, so it should be easy to use that to get the right path (but again, you need to be careful to only include it if it's actually necessary). - Alexander Malmberg ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
