Subject: FVWM: 2.1.5 build on HP-UX fails

From: "A.W.Payne" <[email-masked]>
Date: Wed, 16 Dec 1998 15:52:43 +0000

I've successfully built fvwm-2.1.5 on a linux platform but on my
HP-UX machine the build fails. Same problem with 2.1.4. My previous
version was 2.0.45.

% uname -a
HP-UX happy B.10.20 A 9000/735 2000468344 two-user license

% gcc -v
Reading specs from
/users/pds/lib/gcc-lib/hppa1.1-hp-hpux10.20/2.7.2/specs
gcc version 2.7.2

% cat config.cache
# This file is a shell script that caches the results of configure
# tests run on this system so they can be shared between configure
# scripts and configure runs.  It is not useful on other systems.
# If it contains results you don't want to keep, you may remove or edit
it.
#
# By default, configure uses ./config.cache as the cache file,
# creating it if it does not exist already.  You can give configure
# the --cache-file=FILE option to use a different cache file; that is
# what configure does when it calls configure scripts in
# subdirectories, so they share the cache.
# Giving --cache-file=/dev/null disables caching, for debugging
configure.
# config.status only pays attention to the cache file if you give it the
# --recheck option to rerun configure.
#
ac_cv_c_const=${ac_cv_c_const=yes}
ac_cv_c_inline=${ac_cv_c_inline=inline}
ac_cv_func_connect=${ac_cv_func_connect=yes}
ac_cv_func_div=${ac_cv_func_div=yes}
ac_cv_func_gethostbyname=${ac_cv_func_gethostbyname=yes}
ac_cv_func_gethostname=${ac_cv_func_gethostname=yes}
ac_cv_func_gettimeofday=${ac_cv_func_gettimeofday=yes}
ac_cv_func_memcpy=${ac_cv_func_memcpy=yes}
ac_cv_func_memmove=${ac_cv_func_memmove=yes}
ac_cv_func_mkfifo=${ac_cv_func_mkfifo=yes}
ac_cv_func_putenv=${ac_cv_func_putenv=yes}
ac_cv_func_remove=${ac_cv_func_remove=yes}
ac_cv_func_select=${ac_cv_func_select=yes}
ac_cv_func_setvbuf=${ac_cv_func_setvbuf=yes}
ac_cv_func_setvbuf_reversed=${ac_cv_func_setvbuf_reversed=no}
ac_cv_func_shmat=${ac_cv_func_shmat=yes}
ac_cv_func_socket=${ac_cv_func_socket=yes}
ac_cv_func_strcasecmp=${ac_cv_func_strcasecmp=yes}
ac_cv_func_strchr=${ac_cv_func_strchr=yes}
ac_cv_func_strdup=${ac_cv_func_strdup=yes}
ac_cv_func_strerror=${ac_cv_func_strerror=yes}
ac_cv_func_strftime=${ac_cv_func_strftime=yes}
ac_cv_func_strncasecmp=${ac_cv_func_strncasecmp=yes}
ac_cv_func_strstr=${ac_cv_func_strstr=yes}
ac_cv_func_strtol=${ac_cv_func_strtol=yes}
ac_cv_func_sysconf=${ac_cv_func_sysconf=yes}
ac_cv_func_uname=${ac_cv_func_uname=yes}
ac_cv_func_usleep=${ac_cv_func_usleep=yes}
ac_cv_func_vfprintf=${ac_cv_func_vfprintf=yes}
ac_cv_func_waitpid=${ac_cv_func_waitpid=yes}
ac_cv_have_x=${ac_cv_have_x=have_x='yes 	
ac_x_includes=/users/pds/X11R5/include
ac_x_libraries=/users/pds/X11R5/lib'}
ac_cv_header_X11_xpm_h=${ac_cv_header_X11_xpm_h=yes}
ac_cv_header_fcntl_h=${ac_cv_header_fcntl_h=yes}
ac_cv_header_getopt_h=${ac_cv_header_getopt_h=no}
ac_cv_header_limits_h=${ac_cv_header_limits_h=yes}
ac_cv_header_malloc_h=${ac_cv_header_malloc_h=yes}
ac_cv_header_memory_h=${ac_cv_header_memory_h=yes}
ac_cv_header_minix_config_h=${ac_cv_header_minix_config_h=no}
ac_cv_header_stdarg_h=${ac_cv_header_stdarg_h=yes}
ac_cv_header_stdc=${ac_cv_header_stdc=yes}
ac_cv_header_stdlib_h=${ac_cv_header_stdlib_h=yes}
ac_cv_header_string_h=${ac_cv_header_string_h=yes}
ac_cv_header_sys_select_h=${ac_cv_header_sys_select_h=no}
ac_cv_header_sys_systeminfo_h=${ac_cv_header_sys_systeminfo_h=no}
ac_cv_header_sys_wait_h=${ac_cv_header_sys_wait_h=yes}
ac_cv_header_unistd_h=${ac_cv_header_unistd_h=yes}
ac_cv_lib_ICE_IceConnectionNumber=${ac_cv_lib_ICE_IceConnectionNumber=yes}
ac_cv_lib_Xpm_XpmReadFileToXpmImage=${ac_cv_lib_Xpm_XpmReadFileToXpmImage=yes}
ac_cv_lib_dnet_dnet_ntoa=${ac_cv_lib_dnet_dnet_ntoa=no}
ac_cv_lib_dnet_stub_dnet_ntoa=${ac_cv_lib_dnet_stub_dnet_ntoa=no}
ac_cv_lib_fl_yywrap=${ac_cv_lib_fl_yywrap=yes}
ac_cv_lib_readline_readline=${ac_cv_lib_readline_readline=no}
ac_cv_lib_rplay_rplay_create=${ac_cv_lib_rplay_rplay_create=no}
ac_cv_path_FVWM_CPP=${ac_cv_path_FVWM_CPP=/lib/cpp}
ac_cv_path_install=${ac_cv_path_install='/opt/imake/bin/install -c'}
ac_cv_prog_CC=${ac_cv_prog_CC=gcc}
ac_cv_prog_CPP=${ac_cv_prog_CPP='gcc -E'}
ac_cv_prog_CXX=${ac_cv_prog_CXX=c++}
ac_cv_prog_LEX=${ac_cv_prog_LEX=flex}
ac_cv_prog_LN_S=${ac_cv_prog_LN_S='ln -s'}
ac_cv_prog_RANLIB=${ac_cv_prog_RANLIB=ranlib}
ac_cv_prog_YACC=${ac_cv_prog_YACC='bison -y'}
ac_cv_prog_cc_cross=${ac_cv_prog_cc_cross=no}
ac_cv_prog_cc_g=${ac_cv_prog_cc_g=yes}
ac_cv_prog_cc_works=${ac_cv_prog_cc_works=yes}
ac_cv_prog_cxx_cross=${ac_cv_prog_cxx_cross=no}
ac_cv_prog_cxx_g=${ac_cv_prog_cxx_g=yes}
ac_cv_prog_cxx_works=${ac_cv_prog_cxx_works=yes}
ac_cv_prog_gcc=${ac_cv_prog_gcc=yes}
ac_cv_prog_gxx=${ac_cv_prog_gxx=yes}
ac_cv_prog_lex_root=${ac_cv_prog_lex_root=lex.yy}
ac_cv_prog_lex_yytext_pointer=${ac_cv_prog_lex_yytext_pointer=yes}
ac_cv_prog_make_make_set=${ac_cv_prog_make_make_set=yes}
ac_cv_type_off_t=${ac_cv_type_off_t=yes}
ac_cv_type_pid_t=${ac_cv_type_pid_t=yes}
ac_cv_type_signal=${ac_cv_type_signal=void}
ac_cv_type_size_t=${ac_cv_type_size_t=yes}

% make
No suffix list.
        make  all-recursive
No suffix list.
Making all in libs
        gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..
-I/users/pds/X11R5/include     -g -O2 -c ClientMsg.c
        gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..
-I/users/pds/X11R5/include     -g -O2 -c GetFont.c
In file included from GetFont.c:10:
fvwmlib.h:115: parse error before `*'
*** Error exit code 1

Stop.

fvwmlib.h line 115 is :
void color_reduce_pixmap(XpmImage *, int);

...the patch reducing the number of colours used by pixmaps. Does
anyone know what the problem is ? Any help greatly appreciated.

--
Adrian Payne
Philips Research Labs.
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Wed, 16 Dec 1998 11:15:35 -0500

> anyone know what the problem is ? Any help greatly appreciated.

Wild guess: your xpm library is too old.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Dec 1998 17:25:36 +0100

> Wild guess: your xpm library is too old.

We still have a documentation bug open for this. We had a coredump
with Xpm-4.7 and none with Xpm-4.11. What is your version number?

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: [email-masked] (Paul D. Smith)
Date: 16 Dec 1998 11:34:08 -0500

%% "A.W.Payne" <[email-masked]> writes:

  awp>         gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/users/pds/X11R5/include -g -O2 -c GetFont.c
  awp> In file included from GetFont.c:10:
  awp> fvwmlib.h:115: parse error before `*'
  awp> *** Error exit code 1

  awp> fvwmlib.h line 115 is :
  awp> void color_reduce_pixmap(XpmImage *, int);

It looks to me like your XPM installation is bad; that error usually
means that that type (XpmImage) is unknown.  It's supposed to be defined
in xpm.h, which your configure output says you have?  Maybe you have an
old version?

My xpm.h has this for versions and works fine:

  #define XpmFormat 3
  #define XpmVersion 4
  #define XpmRevision 8

Do you have an xpm.h in /users/pds/X11R5/include/X11 ?
How did you invoke configure?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL: http://fvwm.math.uh.edu/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "Randall S. Winchester" <[email-masked]>
Date: Wed, 16 Dec 1998 11:47:26 -0500 (EST)

On Wed, 16 Dec 1998, Dominik Vogt wrote:

: On Wed, Dec 16, 1998 at 11:15:35AM -0500, Dan Espen wrote:
: > "A.W.Payne" <[email-masked]> writes:
: > > fvwmlib.h:115: parse error before `*'
: > > *** Error exit code 1
: > > 
: > > Stop.
: > > 
: > > fvwmlib.h line 115 is :
: > > void color_reduce_pixmap(XpmImage *, int);
: > 
: > Wild guess: your xpm library is too old.
: 
: We still have a documentation bug open for this. We had a coredump
: with Xpm-4.7 and none with Xpm-4.11. What is your version number?

What is an "Xpm-4.11"? 

The xpm home page as documented in the FAQ points to;

http://www.inria.fr/koala/lehors/xpm.html

The most recent version on ftp://koala.inria.fr/pub/xpm/
is xpm-3.4k (march 19th) which we have installed.

Randall

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 16 Dec 1998 18:05:22 +0100

> : with Xpm-4.7 and none with Xpm-4.11. What is your version number?

Ah, um, I took these version numbers from the installation on
my home system (? puzzled ?) 

Dominik

---

From: [email-masked] (Paul D. Smith)
Date: 16 Dec 1998 12:13:40 -0500

%% "Randall S. Winchester" <[email-masked]> writes:

  rsw> : We still have a documentation bug open for this. We had a coredump
  rsw> : with Xpm-4.7 and none with Xpm-4.11. What is your version number?

  rsw> What is an "Xpm-4.11"? 

  rsw> The xpm home page as documented in the FAQ points to;

  rsw> http://www.inria.fr/koala/lehors/xpm.html

  rsw> The most recent version on ftp://koala.inria.fr/pub/xpm/
  rsw> is xpm-3.4k (march 19th) which we have installed.

If we know which versions are bad (or alternatively, the lowest "known
good" version) we can probably easily construct a configure test for it.

---

From: "A.W.Payne" <[email-masked]>
Date: Wed, 16 Dec 1998 18:44:28 +0000

> Do you have an xpm.h in /users/pds/X11R5/include/X11 ?

I did, but someone had overwritten it with an old version which was xpm
format 2, when they installed some other program. Having now put back an
xpm format 3 xpm.h in my include directory it's compiled OK. You were
spot on Paul, thanks very much for the help.

---

From: Dan Espen <[email-masked]>
Date: Wed, 16 Dec 1998 13:58:44 -0500

> spot on Paul, thanks very much for the help.

We are still left with user unfriendly output discovered too late.

I notice that we check for the file "xpm.h" during configure, but
never try to #include it.

I'm  still not totally up  to speed on autoconf,  but wouldn't it make
more  sense  to change the  xpm  sensing logic to  use  the header and
actually  include  an "XpmImage *"  in the  little sample program that
configure uses?

---

From: [email-masked] (Brian Barrick)
Date: Wed, 16 Dec 1998 11:18:24 -0800 (PST)

> actually  include  an "XpmImage *"  in the  little sample program that

Here is a snippet from the configure.in file from a recent XEmacs (21.0)
release.  I'm no expert in autoconf, but I hope this helps.

	- Brian

  dnl Autodetect Xpm
  xpm_problem=""
  if test -z "$with_xpm"; then
    AC_MSG_CHECKING(for Xpm - no older than 3.4f)
    xe_check_libs=-lXpm
    AC_TRY_RUN([#include <X11/xpm.h>
    int main(int c, char **v) {
    return c == 1 ? 0 :
      XpmIncludeVersion != XpmLibraryVersion() ? 1 :
      XpmIncludeVersion < 30406 ? 2 : 0 ;}],
    [./conftest dummy_arg; xpm_status=$?;
      if test "$xpm_status" = "0"; then
        with_xpm=yes;
      else
        with_xpm=no;
        if test "$xpm_status" = "1"; then
          xpm_problem="Xpm library version and header file version don't match!"
        elif test "$xpm_status" = "2"; then
          xpm_problem="Xpm library version is too old!"
        else
          xpm_problem="Internal xpm detection logic error!"
        fi
        echo "
*** WARNING *** $xpm_problem
  I'm not touching that with a 10-foot pole!
  If you really want to use the installed version of Xpm, rerun
  configure and add '--with-xpm=yes', but don't blame me if XEmacs crashes!"
    fi],
    [with_xpm=no])
    xe_check_libs=
    AC_MSG_RESULT($with_xpm)
  fi
  if test "$with_xpm" = "yes"; then
    AC_DEFINE(HAVE_XPM)
    XE_PREPEND(-lXpm, libs_x)
    AC_MSG_CHECKING(for \"FOR_MSW\" xpm)
    xe_check_libs=-lXpm
    AC_TRY_LINK(, [XpmCreatePixmapFromData()],
    [xpm_for_msw=no],
    [xpm_for_msw=yes])
    xe_check_libs=
    AC_MSG_RESULT($xpm_for_msw)
    if test "$xpm_for_msw" = "yes"; then
      AC_DEFINE(FOR_MSW)
    fi
  fi

---

From: [email-masked] (Paul D. Smith)
Date: 16 Dec 1998 16:24:57 -0500

%% [email-masked] (Brian Barrick) writes:

  bb> Here is a snippet from the configure.in file from a recent XEmacs (21.0)
  bb> release.  I'm no expert in autoconf, but I hope this helps.

Ah, good; this is exactly what I meant when I said we could "add a check
into configure".

Now, is our requirement for xpm the same as XEmacs' (looks like they
want at least 3.4f)?  Do we need something later?  Will an earlier
release work?

I can add this check for now and we can adjust later, I suppose.

---

From: Dan Espen <[email-masked]>
Date: Wed, 16 Dec 1998 16:37:06 -0500

> I can add this check for now and we can adjust later, I suppose.

I think it's still a mystery, which is why  I favored an approach that
attempted  to test the functionality  we  need rather  than a  release
number.  Of course, it is  true, when we are  all done, a message that
says "you need  a release > than ???",  is better than a message  that
just says your xpm library doesn't work.

I know that 3.4j (4.10) works.

> --
>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: [email-masked] (Paul D. Smith)
Date: 16 Dec 1998 18:34:11 -0500

>> want at least 3.4f)?  Do we need something later?  Will an earlier

  de> I think it's still a mystery, which is why  I favored an approach that
  de> attempted  to test the functionality  we  need rather  than a  release
  de> number.  Of course, it is  true, when we are  all done, a message that
  de> says "you need  a release > than ???",  is better than a message  that
  de> just says your xpm library doesn't work.

The question is, is _any_ xpm.h that contains XpmImage good enough?  I
thought there were issues even with some later, but not late enough,
versions of Xpm.