Subject: trouble to build after Makefile.am changed

From: Dominik Vogt <[email-masked]>
Date: Mon, 27 Sep 1999 17:10:21 +0200

Recently (for a few months) I have problems building fvwm after
one of the Makefile.am files has changed (well, I at least I guess
that this is the problem).  If this happens, 'make' calls automake,
autoconf and reruns configure.  automake and autoconf run through,
but configure always fails with this message:

----------------- snip ----------------
/bin/sh ./config.status --recheck
running /bin/sh ./configure  -without-cxx --enable-gnome --no-create --no-recursion
loading cache ./config.cache
checking for a BSD compatible install... (cached) /usr/bin/ginstall -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking whether to enable debugging messages... no
checking whether to enable multibyte character support... no
checking whether to enable workaround for flickering windows during move... no
checking whether to enable modal dialogs for applications... yes
checking whether to enable shape extensions... yes
checking whether to enable GNOME Window Manager Hints... yes
checking imagepath... /usr/include/X11/bitmaps:/usr/include/X11/pixmaps
checking for gcc... (cached) gcc
checking whether the C compiler (gcc -g -O2 -Wall -Werror ) works... no
configure: error: installation or configuration problem: C compiler cannot creat
e executables.
make: *** [config.status] Error 1
---------------------------------------

(If I don't configure with -without-cxx, I get the same error, but
with 'C++' instead of 'C'.)

To recompile I have to run configure manually with
'./configure --enable-gnome'. Note that I don't need '-without-cxx' here.
But the next time a Makefile.am changes I will get the 'C++' error.

What can I do to prevent this?

Bye

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://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: [email-masked] (Paul D. Smith)
Date: 28 Sep 1999 13:46:24 -0400

%% Dominik Vogt <[email-masked]> writes:

  dv> Recently (for a few months) I have problems building fvwm after
  dv> one of the Makefile.am files has changed (well, I at least I guess
  dv> that this is the problem).  If this happens, 'make' calls automake,
  dv> autoconf and reruns configure.

Hmm.  Weird.  Changing a Makefile.am should _NOT_ cause autoconf or
configure to re-run, it should just automake that one Makefile.am.
autoconf/configure should only rebuild if you change configure.in, or
the acinclude.m4 or similar files.

  dv> checking for gcc... (cached) gcc
  dv> checking whether the C compiler (gcc -g -O2 -Wall -Werror ) works... no
  dv> configure: error: installation or configuration problem: C compiler cannot create executables.

Do you normally need to compile with special LDFLAGS?  Right now
autoconf/automake doesn't preserve special values that are set through
the environment, like this:

  $ LDFLAGS='-L/usr/local/lib -R/usr/local/lib' ./configure ...

I have to do this; if you do this then when you re-run configure it
won't have the special values of LDFLAGS anymore and won't configure
correctly.  I always have to configure by hand.

The next version of automake fixes this, and caches _all_ the
interesting values.  I can't wait.

  dv> (If I don't configure with -without-cxx, I get the same error, but
  dv> with 'C++' instead of 'C'.)

This is in the 2.3.x branch?!?!  We don't (shouldn't) check for C++ at
all here.  --without-cxx should be essentially ignored, and configure
should never look for C++ of any kind.

Remove your config.cache and config.restart files.  In fact, I'd do a
distclean.  When I build fvwm I actually don't build it in the tree but
in a remote directory.  That way when I want to I can just rm -rf and
all that config.cache, etc. stuff just goes away.  You need GNU make for
this, though.

  dv> To recompile I have to run configure manually with './configure
  dv> --enable-gnome'. Note that I don't need '-without-cxx' here.  But
  dv> the next time a Makefile.am changes I will get the 'C++' error.

Very, very strange.  Are you sure you're not somehow mixing 2.2.x and
2.3.x workspaces?  You shouldn't move back and forth between these
within the same view (checkout); it's dangerous.  When was the last time
you checked out a completely new version of the CVS code from scratch?

Look in your configure.in; you should see all the C++ stuff commented
out with "dnl".  Look in the generated configure; there should be no
reference at all to c++ or cxx (except one subst of CXXFLAGS).

Try "cvs status configure.in" and make sure you don't have any sticky
tags or dates set.  My version is 1.79 and I believe that's the latest.

-- 
-------------------------------------------------------------------------------
 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://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, 29 Sep 1999 00:57:36 +0200

On Tue, Sep 28, 1999 at 01:46:24PM -0400, Paul D. Smith wrote:
> ...

...

[80% of my original mail deleted when I found out the problem]

> tags or dates set.  My version is 1.79 and I believe that's the latest.

Hm, I checked out when I arrived at home. At work I hagain had this
problem, so if it's persistent I should see it here again... 

Yes, same error. But this time './configure --enable-gnome' fixes it.
I don't have to remove config.cache. Strange.

----- some more experimenting -----

Gack! The command line I use to call 'make' makes the difference.
I have developed a habit to run make always as

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

This knocks out configure (if it has to run)...
Oh well, the '-Wall -Werror' is passed to the C compiler test in
configure which in turn produces this output in config.log:

-------------- snip --------------
configure:1004: checking for gcc
configure:1117: checking whether the C compiler (gcc -g -O2 -Wall -Werror ) works
configure:1133: gcc -o conftest -g -O2 -Wall -Werror   conftest.c  1>&5
cc1: warnings being treated as errors
configure:1130: warning: return-type defaults to `int'
configure: failed program was:

#line 1128 "configure"
#include "confdefs.h"

main(){return(0);}
-------------- snip --------------

:-) Perhaps the test program had better been 

  int main(){return(0);}
  ^^^

I see that all test programs except the tests for the C compiler,
alloca stack direction and setvbuf already have 'int' before
'main'.  Is that an autoconf bug or can we change that in our tree?

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: [email-masked] (Paul D. Smith)
Date: 29 Sep 1999 10:08:41 -0400

%% Dominik Vogt <[email-masked]> writes:

  dv> Gack! The command line I use to call 'make' makes the difference.
  dv> I have developed a habit to run make always as

  dv>   make CFLAGS="-g -O2 -Wall -Werror"

Oh yeah.  Doh!  I didn't even notice that.

Yes, you don't want to do that; configure won't like -Werror in
particular, and it even won't like -Wall for some tests (some tests
produce output with -Wall that configure then interprets as a problem).

  dv> I see that all test programs except the tests for the C compiler,
  dv> alloca stack direction and setvbuf already have 'int' before
  dv> 'main'.  Is that an autoconf bug or can we change that in our
  dv> tree?

It's an autoconf issue.  We _could_ fix it, by overriding the default
autoconf macros for those tests with our own, but I don't want to go
there.

I think you should rather report it to the autoconf folks.