Re: Compile Issues
Dominik Vogt writes: > 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 Oh! I thought it was bombing already, and that's what you were trying to prevent. Yes, what you describe looks pretty nasty. -- Eric Gillespie <*> [EMAIL PROTECTED] 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 http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
Dominik Vogt writes: > On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote: > > Dominik Vogt writes: > > > On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote: > 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. -- Dan Espen E-mail: [EMAIL PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Wed, Sep 18, 2002 at 08:35:22AM -0400, Dan Espen wrote: > Dominik Vogt writes: > > On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote: > > [snip] > > > 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. > > > > 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: > > 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 Does it compile if you remove the "conts" bits? Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Wed, Sep 18, 2002 at 08:33:32AM -0500, Eric Gillespie wrote: > Dominik Vogt writes: [snip] > > 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. > > I guess you meant -Werror? I don't see what you're trying to > accomplish though. 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 ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
Dominik Vogt 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 > > $ make CFLAGS="-Wall -Werror -O2 -g" > > configure is rerun automatically with the CFLAGS I passed to > make. 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. > 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. I guess you meant -Werror? I don't see what you're trying to accomplish though. -- Eric Gillespie <*> [EMAIL PROTECTED] 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 http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
Dominik Vogt writes: > On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote: > [snip] > > 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. > > 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: 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 PROTECTED] 444 Hoes Lane Room RRC 1C-214 Phone: (732) 699-5570 Piscataway, NJ 08854 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Wed, Sep 18, 2002 at 01:27:09PM +0200, Ulrich Fahrenberg wrote:
> On Wed, 18 Sep 2002, Dominik Vogt wrote:
>
> > --- warn.c ---
> > #include
> > 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;
> > }
> > --
>
> > 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.
Is that an ANSI C compiler? If it is, what problems does it have?
Bye
Dominik ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Wed, 18 Sep 2002, Dominik Vogt wrote:
> --- warn.c ---
> #include
> 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;
> }
> --
> 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
--
Ulrich Fahrenberg -- http://www.math.auc.dk/~uli
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Wed, Sep 18, 2002 at 10:30:52AM +0200, fvwm-workers wrote:
[snip]
> 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.
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
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 ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Tue, Sep 17, 2002 at 02:00:27PM -0500, Eric Gillespie wrote:
> Dominik Vogt 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).
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.
> 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).
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 ^_^ ^_^
--
Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
--
Visit the official FVWM web page at http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
Dominik Vogt 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 PROTECTED]
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 http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [EMAIL PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Tue, Sep 17, 2002 at 12:44:03PM +0200, Ulrich Fahrenberg wrote: > On Tue, 17 Sep 2002, Dominik Vogt wrote: > > > On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: > > > > > 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. > > 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 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. > , 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, 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 > is not A Bad Thing, but maybe it deserves to be mentioned in the > INSTALL file). Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Tue, 17 Sep 2002, Dominik Vogt wrote: > On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: > > > 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. 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 -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Compile Issues
On Tue, Sep 17, 2002 at 01:54:56AM -0400, Suzanne Skinner wrote: > 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? 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. > 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... Fixed. > --- 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.hTue 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) Applied. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Compile Issues
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 PROTECTED] - http://www.igs.net/~tril/ --- gnome.h.origTue 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)
