[Pan-users] Re: Can no longer ./configure pan 0.131

[Duncan]

Van Reuther <address@hidden> posted
address@hidden, excerpted below, on  Mon, 30 Jul 2007 00:45:59
-0400:

> checking whether to enable maintainer-specific portions of Makefiles...
> no checking for g++... no
> checking for c++... no
> checking for gpp... no
> checking for aCC... no
> checking for CC... no
> checking for cxx... no
> checking for cc++... no
> checking for cl... no
> checking for FCC... no
> checking for KCC... no
> checking for RCC... no
> checking for xlC_r... no
> checking for xlC... no
> checking for C++ compiler default output file name... configure: error:
> C++ compiler cannot create executables See `config.log' for more
> details.
> 
> 
> What struck me odd is c++... no.
> I thought c++ is the cpp package? If so, I have:
> 
> ~$ dpkg -l | grep cpp
> ii cpp         4:4.1.2-3    The GNU C preprocessor (cpp) 
> ii cpp-3.3     1:3.3.6-15   The GNU C preprocessor
> ii cpp-3.4     3.4.6-6      The GNU C preprocessor
> ii cpp-4.1     4.1.2-14     The GNU C preprocessor
> ii libpcrecpp0 6.7-1        Perl 5 Compatible Regular Expression Library

AFAIK the GNU C++ compiler is g++, cpp is as above the preprocessor,
which is different.  However, you probably have it and the configure
script just isn't seeing it.

> I skimmed config.log a little bit and some of the other things it says
> are missing are actually on my file system. I refrain from pasting it
> here in case I'm chasing the wrong path but will supply if requested.
> 
> Would something like this be a pan bug or a configure bug or a bug
> somewheres else?

Well, I'd call it a pan configure bug. =8^P  I don't run Debian and
don't code C or C++, tho I do run Gentoo so do my share of compiling.
=8^)  So I don't know anything Debian specific.  Perhaps as with Gentoo,
you have a way to set the system compiler to one of several gcc versions?
If so, that might have been screwed up by your update and all you need to
do is reset it to point at a valid compiler again.

You can also set the compiler path in either the environment, or likely,
with configure options.  That might or might not help, but it should
"just work" and that wouldn't fix the problem, only work around it.

As for troubleshooting, config.log has line numbers that match the
configure script, which is simple shell scripting.  If you are decently
good at bash, you should be able to follow the script and figure out
what the various test functions are doing.  Here, I've found that often
clarifies exactly what's going wrong, which isn't always exactly the
error that's reported.  The reported error is right, in terms of what
the configure script is testing, but sometimes, it isn't testing exactly
what it says it's testing.  Some tests fail on compile WARNINGS as well
as compile errors.  If one tries to use -freorder-blocks-and-partition
in their CXXFLAGS (for C++ programs, as opposed to CFLAGS, forC programs),
for instance, many C++ programs will bomb out during configure, because
that flag won't work with exceptions (which most C++ code uses), and gcc
emits a warning to that effect and disables it, but the configure often
interprets that warning as an error and stops, even tho it could safely
continue since gcc is just saying it can't use that flag with this
particular code and that it removed it.  For that reason, I have
different C and C++ flags even tho they are almost the same, and
simply omit the -freorder-blocks-and-partition flag from my CXXFLAGS
(tho I still use the somewhat weaker -freorder-blocks, without the
partitioning, as that works fine).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman