Van Reuther <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 _______________________________________________ Pan-users mailing list Pan-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-users
