Subject: Compile Issues

From: Suzanne Skinner <[email-masked]>
Date: Tue, 17 Sep 2002 01:54:56 -0400

Fvwm does not compile if Gnome hints and/or EWMH hints are disabled. The
attached patch fixes this.

Also, CFLAGS aren't working at all?

Also also, Fvwm fails to link if compiled without Xinerama, because of the
reference to XineramaQueryScreens (possibly others, haven't checked) in
FScreen.o. Perhaps if -O2 were working it would be safely optimized away...

Suzanne

-- 
[email-masked] - http://www.igs.net/~tril/
--- gnome.h.orig	Tue Sep 17 01:35:59 2002
+++ gnome.h	Tue Sep 17 01:35:59 2002
@@ -65,7 +65,7 @@
 #else
 
 #define GNOME_Init()
-#define GNOME_ProcessClientMessage(fwin, ev) 0
+#define GNOME_ProcessClientMessage(fwin) 0
 #define GNOME_ButtonFunc(eventp, w, fwin, context, action, Module)
 #define GNOME_ProxyButtonEvent(ev)
 #define GNOME_ShowDesks(eventp, w, fwin, context, action, Module)
--- ewmh.h.orig	Tue Sep 17 01:35:58 2002
+++ ewmh.h	Tue Sep 17 01:35:58 2002
@@ -117,8 +117,8 @@
 /* ewmh_conf.c */
 
 /* ewmh_events.c */
-#define EWMH_ProcessClientMessage(x, y) 0
-#define EWMH_ProcessPropertyNotify(x, y)
+#define EWMH_ProcessClientMessage(x) 0
+#define EWMH_ProcessPropertyNotify(x)
 
 /* ewmh_icon.c */
 #define EWMH_DoUpdateWmIcon(x,y,z)

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 17 Sep 2002 11:16:53 +0200

> Also, CFLAGS aren't working at all?

They should be working as usual.  I have disabled them in
configure because they often cause some tests to fail.  How did
you specify the flags?  When I run

  $ make CFLAGS="..."

it works as it always did.

> FScreen.o. Perhaps if -O2 were working it would be safely optimized away...

Fixed.

> +++ gnome.h	Tue Sep 17 01:35:59 2002

Applied.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Ulrich Fahrenberg <[email-masked]>
Date: Tue, 17 Sep 2002 12:44:03 +0200 (MEST)

> it works as it always did.

If I understand the True Gnu Way Of Doing Things right, configure
should read any CFLAGS (and CXXFLAGS and LDFLAGS and ...) you have set
in your shell and write them to the appropriate Makefiles, such that
afterwards,

	make CFLAGS="$CFLAGS"

should be equivalent to simply saying

	make

, and
	make CFLAGS="aVerySpecialFlag"

would be the same as

	make CFLAGS="aVerySpecialFlag $CFLAGS"

Of course there can be good reasons to disable CFLAGS recognition in
configure, but then things do not work the True Gnu Way anymore (which
is not A Bad Thing, but maybe it deserves to be mentioned in the
INSTALL file).

Just my 2c,
Uli

-- 
Ulrich Fahrenberg -- http://www.math.auc.dk/~uli

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 17 Sep 2002 14:06:16 +0200

> should be equivalent to simply saying

Well, if it's set in your shell, make inherits them automatically
unless you unset them between configure an make.

(testing)

But it doesn't work.  Autoconf seems to override the shell
settings.

> configure,

Yes, there is a very good reason:  configure chokes on the -Werror
flag and produces more or less random test results.  This can be
hell to debug.  Maybe I can find a way to enable the original
CFLAGS again before they are placed in the Makefiles.

> but then things do not work the True Gnu Way anymore (which

Bye

Dominik ^_^  ^_^

---

From: Eric Gillespie <[email-masked]>
Date: Tue, 17 Sep 2002 14:00:27 -0500

Dominik Vogt <[email-masked]> writes:

> Yes, there is a very good reason: configure chokes on the
> -Werror flag and produces more or less random test results.
> This can be hell to debug.  Maybe I can find a way to enable
> the original CFLAGS again before they are placed in the
> Makefiles.

That is not generally sufficient, nor is setting the variables on
the make command line.  There is a reason for the standard
behavior.  If you have libraries installed outside the standard
search path (/usr), you need to set CPPFLAGS and LDFLAGS before
running configure.  The most famous examples are /usr/X11R6 and
/usr/local (yes, i know most (all?) GNU/Linux distributions put
those on the standard search path, but that's just lunacy), but
there are also things like /opt and /usr/pkg (where NetBSD
packages are installed).

And no, it isn't generally sufficient for the configure script to
set the appropriate options itself.  That is necessary for the
standard options (-L and -I), but not sufficient because
sometimes platform- or site-specific settings are needed.  For
example, on NetBSD we always set an rpath with -Wl,-R, but on
Darwin the linker will explode since it has no -R option.
Configure scripts would be a mess if they had to handle this sort
of thing.

I say "generally" because, in my experience, it is not necessary
to set these variables with fvwm.  I think it's picking up
/usr/{X11R6,pkg}/{include,pkg} from the gtk-config script.  So
the above paragraph may not apply to Fvwm (someone not using the
Gtk stuff will have to comment), but it's good to keep in mind
anyway.  And it may be worth sticking with the standard behavior
so as not to violate the principle of least surprise, if for no
other reason.

As for the -Werror example, that is just user error.  There are
things you need to put into CPPFLAGS (defines and includes), and
there are things you can put in there that will break (code
generation or scanning flags).

--  
Eric Gillespie <*> [email-masked]

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 10:30:52 +0200

> there are also things like /opt and /usr/pkg (where NetBSD

Okay, but what about CFLAGS?  I don't care much about the CPPFLAGS
or LDFLAGS.  And by the way, the paths of all libraries that fvwm
uses can be set with configure options.

> generation or scanning flags).

No, it isn't necessarily a user error.  Sometimes, when one of the
autoconf/automake files has changed, an I type

  $ make CFLAGS="-Wall -Werror -O2 -g"

configure is rerun automatically with the CFLAGS I passed to make.
When configure is not run, these options are fine.  It's tedious
to keep that in mind.  Last time I wasted half an hour hunting
bugs that were not there just because configure detected a
"non-ANSI" C compiler and did funny things in config.h.

Of course I can just strip the -Werror from the CFLAGS, but
non-gcc users won't profit then.

How about this:  write a small test program that issues lots of
warnings with -Wall and AC_TRY_COMPILE it.  When that fails,
configure bugs out with an error message.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 11:11:03 +0200

On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
[snip]
> configure bugs out with an error message.

This is the test code I came up with.  To the best of my
knowledge, every ANSI C compiler should be able to compile it, but
not without warnings:

----------------------- warn.c -------------------
  #include <stdio.h>
  main(const i, const int * const p)
  {
    char *c;

    switch (*p = p = *c)
    {
    case 0:
      printf("%p", c, p);
    }
    *c = &i;
    c = p;
    while (1 || (unsigned int)3 >= 0 ||
           ((int)-1) == ((unsigned int)1));

    return;
  }
--------------------------------------------------

It's meant to provoke a number of non-fatal warnings that would
cause compilation to fail with -Werror or a similar option in
other compilers.  It's very important that it doesn't fail without
such an option.  So I ask everybody to review it and/or try to
compile it with

  $ cc warn.c

If it doesn't compile with any *C* compiler, please report back.
I'm fully aware that it won't compile on *C++* compilers.

Bye

Dominik ^_^  ^_^

---

From: Ulrich Fahrenberg <[email-masked]>
Date: Wed, 18 Sep 2002 13:27:09 +0200 (MEST)

> So I ask everybody to review it and/or try to compile it

I'm at work, SPARC Solaris 5.8. gcc complains a lot many times, but
compiles happily, as expected. But Sun's own proprietary forte-cc
fails to compile it.

uli

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 13:39:01 +0200

> compiles happily, as expected. But Sun's own proprietary forte-cc

Is that an ANSI C compiler?  If it is, what problems does it have?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 18 Sep 2002 08:35:22 -0400

> knowledge, every ANSI C compiler should be able to compile it, but

Solaris 8 (yes, its an ANSI compiler):

fork> cc dominik.c           
"dominik.c", line 6: left operand must be modifiable lvalue: op "="
"dominik.c", line 6: left operand must be modifiable lvalue: op "="
"dominik.c", line 11: warning: improper pointer/integer combination: op "="
"dominik.c", line 12: warning: assignment type mismatch:
        pointer to char "=" const pointer to const int
cc: acomp failed for dominik.c
fork> cc -V       
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15

HPUX11.11:

peterpan> cc dominik.c
cc: "dominik.c", line 6: error 1549: Modifiable lvalue required for assignment operator.
cc: "dominik.c", line 6: error 1549: Modifiable lvalue required for assignment operator.
cc: "dominik.c", line 11: warning 526: Pointer implicitly converted to integral value in assignment.
cc: "dominik.c", line 12: warning 611: Qualifiers are not assignment-compatible.
peterpan> cc -V dominik.c
cpp.ansi: HP92453-01 B.11.11.02 HP C Preprocessor (ANSI)
ccom: HP92453-01 B.11.11.02 HP C Compiler

AIX 5.1:

dumbo> cc dominik.c
"dominik.c", line 6.18: 1506-068 (W) Operation between types "const int* const" and "unsigned char" is not allowed.
"dominik.c", line 6.16: 1506-025 (S) Operand must be a modifiable lvalue.
"dominik.c", line 11.6: 1506-068 (W) Operation between types "unsigned char" and "const int*" is not allowed.
"dominik.c", line 12.5: 1506-068 (W) Operation between types "unsigned char*" and "const int* const" is not allowed.
dumbo> cc -V
  VisualAge C++ Professional / C for AIX Compiler, Version 5

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

---

From: Eric Gillespie <[email-masked]>
Date: Wed, 18 Sep 2002 08:33:32 -0500

Dominik Vogt <[email-masked]> writes:

> Okay, but what about CFLAGS?  I don't care much about the

You're probably OK resetting CFLAGS; anything someone will need
to add to build it would be a define, include path, or library
path, i should think.  You never know though, and there's still
the principle of least surprise, since fvwm's configure script
will behave differently than other configure scripts.

> CPPFLAGS or LDFLAGS.  And by the way, the paths of all
> libraries that fvwm uses can be set with configure options.

Sure, it will add a -L, but not a -Wl,-R or any other platform-
or site-specific flag.

> No, it isn't necessarily a user error.  Sometimes, when one of
> the autoconf/automake files has changed, an I type
> 

Ah, good old automake.  Rerunning the configure script is evil,
for this reason and many others.  Since my advice "don't use
automake" probably isn't something anyone is interested in
hearing, resetting only CFLAGS like you suggested will probably
be OK.

While we're on this, let me point out one of the other reasons
rerunning the configure script is evil.

0 fvwm% cat ../configure/fvwm
#! /bin/sh

CFLAGS=-g
CPPFLAGS='-I/usr/pkg/include'
LDFLAGS="-Wl,-R/usr/pkg/lib -L/usr/pkg/lib -Wl,-R/usr/X11R6/lib"
export CFLAGS CPPFLAGS LDFLAGS

sh ./configure \
	--disable-gnome-hints \
	--without-gnome \
	--disable-sm \
	"$@"

I have a similar script for every package i install.  Luckily for
me, the only automake-using package is fvwm, for which my
CPPFLAGS and LDFLAGS settings are apparently unnecessary because
it will pick them up from the gtk-config script.  If it weren't
for that luck, the automake-generated would happily run a
configure script incorrectly and things would explode.

> configure bugs out with an error message.

I guess you meant -Werror?  I don't see what you're trying to
accomplish though.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 15:52:31 +0200

[snip]
> I guess you meant -Werror?  I don't see what you're trying to

Currently:

 $ touch configure.in
 $ make CFLAGS="-Wall -Werror"
 => make reruns configure
 => some configure test programs fail because of the warnings in
    some header files
 => features are detected/missed incorrectly (e.g. AC_C_CONST
    detects a non-ansi compiler and adds "#define const" to
    config.h)
 => bad surprises when compiling (in other words: BOOM)
 => lots of time wasted debugging imagined problems

Hopefully in the future:

 $ touch configure.in
 $ make CFLAGS="-Wall -Werror"
 => make reruns configure
 => configure refuses to run

Of course I'd rather have configure not run automatically.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 18 Sep 2002 15:56:37 +0200

> cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15

Does it compile if you remove the "conts" bits?

Bye

Dominik ^_^  ^_^

---

From: Dan Espen <[email-masked]>
Date: Wed, 18 Sep 2002 10:04:26 -0400

> Does it compile if you remove the "conts" bits?

Yes.

I changed 1 line like this:

main(int i, int * p)

Solaris:

fork> cc dominik.c
"dominik.c", line 6: warning: improper pointer/integer combination: op "="
"dominik.c", line 6: warning: improper pointer/integer combination: op "="
"dominik.c", line 11: warning: improper pointer/integer combination: op "="
"dominik.c", line 12: warning: assignment type mismatch:
        pointer to char "=" pointer to int

HPUX:

peterpan> cc dominik.c
cpp.ansi: HP92453-01 B.11.11.02 HP C Preprocessor (ANSI)
cc: "dominik.c", line 6: warning 526: Pointer implicitly converted to integral value in assignment.
cc: "dominik.c", line 11: warning 526: Pointer implicitly converted to integral value in assignment.
cc: "dominik.c", line 12: warning 604: Pointers are not assignment-compatible.

AIX:

dumbo> cc dominik.c
"dominik.c", line 6.18: 1506-068 (W) Operation between types "int*" and "unsigned char" is not allowed.
"dominik.c", line 6.14: 1506-068 (W) Operation between types "int" and "int*" is not allowed.
"dominik.c", line 11.6: 1506-068 (W) Operation between types "unsigned char" and "int*" is not allowed.
"dominik.c", line 12.5: 1506-068 (W) Operation between types "unsigned char*" and "int*" is not allowed.

---

From: Eric Gillespie <[email-masked]>
Date: Wed, 18 Sep 2002 20:39:45 -0500

>  => lots of time wasted debugging imagined problems

Oh!  I thought it was bombing already, and that's what you were
trying to prevent.  Yes, what you describe looks pretty nasty.