Thu 22 Jul 2010 02:31:51 AM UTC, comment #10:
Paul, I just tried 3.81.91 with the same build environment as before, and everything builds successfully.
"make check" yields a couple of anomalies, however:
Are these a cause for concern?
|
Mon 19 Jul 2010 03:22:08 AM UTC, comment #9:
OK, I think I've fixed this by changing configure.in to look for a declaration for bsd_signal(), not just function linkage. That means actually we'll be using GNU make's version of this function and not the system version. Please try the next pretest when it's out and let me know. If it didn't work please comment here and I'll reopen it.
|
Wed 14 Jul 2010 03:29:24 AM UTC, comment #8:
I believe bsd_signal() is detected because the configure script checks whether the function links, not whether the headers provide a prototype.
The bsd_signal() check itself, as recorded in config.log, is pretty perfunctory:
(I see that AC_CHECK_FUNCS() is used for this in configure.in, which does only check whether a function links.)
Anyway, looking at /usr/include/signal.h (attached), "#define _XOPEN_SOURCE_EXTENDED" is needed to get the bsd_signal() prototype. That allows main.c to compile.
But now I remember where the integer-type error came from. It's a knock-on effect of _X_S_E, causing trouble in the system's own header files:
As originally reported, adding "#define _OSF_SOURCE" does the trick.
(file #20969)
|
Tue 13 Jul 2010 02:03:02 PM UTC, comment #7:
OK, the problem seems to be that in config.h, we have HAVE_BSD_SIGNAL set. But, in the output of the preprocessor for main.c that function is not defined anywhere. So, the C compiler gives it the default prototype where it returns int, instead of returning a function pointer, and hence you get the compile error.
The question is, why does configure determine that HAVE_BSD_SIGNAL is true, but when we compile main.c there is no bsd_signal() prototype?
So a few things. First, can you look into config.log and find the part where we test for bsd_signal() and set HAVE_BSD_SIGNAL, and tell me what the code we compile looks like and what the compiler options are? Also, can you look into the /usr/include/signal.h file on your system and find out what #defines need to be set (or not set), to ensure bsd_signal() is prototyped?
We need to get configure and the compilation of main.c on the same page: either neither one should be able to see the system bsd_signal() (in which case we'll use our own version), or both should be able to see it.
PS. if you put code into the bug comment, please use the verbatim tags to avoid reformatting; see the Markup Reminder section (check the Cookbook link on the menu to the left). Thanks!
|
Tue 13 Jul 2010 05:57:01 AM UTC, comment #6:
I'm attaching a copy of config.h, the bsd_signal() man page, and the preprocessed form of main.c. (I'm using the vendor's compiler, so it's just straight "cc -E", but hopefully that'll show what you need.) Relevant tidbits:
#define HAVE_BSD_SIGNAL 1
#define HAVE_SIGACTION 1
void (bsd_signal(int sig, void (func)(int)))(int);
typedef void (*__sigfp)(int);
(file #20949, file #20950, file #20951)
|
Tue 13 Jul 2010 04:57:57 AM UTC, comment #5:
Hm, that's interesting. Can you check the status of HAVE_BSD_SIGNAL and HAVE_SIGACTION in config.h? Attaching it would be very helpful. Can you check your system to see if there's a man page for bsd_signal() and if so, what it says the calling arguments are?
I need to know if main.c is using our own implementation of bsd_signal(), or whether there's one already on the system. I also need to know (if you can find out) what the underlying type for __sigfp is; it's some kind of function pointer, but which kind?
Ideally if you can get the output of the preprocessor for main.c (but with all the #include and #define lines still there; in GCC for example using the -E -dD) that would be most helpful.
|
Tue 13 Jul 2010 02:27:08 AM UTC, comment #4:
Okay, I pulled down make-3.81.90 and built on the Tru64 system without setting any flags. It looks like only one file is failing now, albeit with a similar error to what I saw before. Here's the output from a second pass of "make -i":
make all-recursive
Making all in glob
Making all in config
No suffix list.
Making all in po
Making all in doc
source='../main.c' object='main.o' libtool=no DEPDIR=.deps depmode=tru64 /usr/local/bin/bash ../config/depcomp cc -std -DLOCALEDIR=\"/usr/local/share/locale\" -DLIBDIR=\"/usr/local/lib\" -DINCLUDEDIR=\"/usr/local/include\" -DHAVE_CONFIG_H -I. -I.. -I../glob -g -c ../main.c
cc: Error: ../main.c, line 992: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGHUP);
--^
cc: Error: ../main.c, line 995: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGQUIT);
--^
cc: Error: ../main.c, line 997: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGINT);
--^
cc: Error: ../main.c, line 998: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGTERM);
--^
cc: Error: ../main.c, line 1011: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGXCPU);
--^
cc: Error: ../main.c, line 1014: In this statement, "bsd_signal(...)" and "(__sigfp)1" cannot be compared for equality or inequality. (noequality)
FATAL_SIG (SIGXFSZ);
--^
cc -std -g -o make ar.o arscan.o commands.o default.o dir.o expand.o file.o function.o getopt.o getopt1.o implicit.o job.o main.o misc.o read.o remake.o remote-stub.o rule.o signame.o strcache.o variable.o version.o vpath.o hash.o getloadavg.o glob/libglob.a
ld:
Can't open: main.o (No such file or directory)
|
Tue 13 Jul 2010 01:22:53 AM UTC, comment #3:
A log would be helpful. The problem is that from what you say, it's not that functions are missing. It seems more like there are errors in the system headers; for example if u_long is not available when compiling getloadavg.c then why not? I can't really test for that in configure.in as far as I can see.
Maybe the logs will be more illuminating.
|
Tue 13 Jul 2010 01:17:32 AM UTC, comment #2:
config.guess returns "alphaev56-dec-osf4.0g".
I would add checks for the missing functions to the configure script, and if not have logic that automatically tries the feature test macros in case the functions aren't found, then at least a note alerting the user that these macros may address the problem.
Would it be helpful if I posted a log of errors encountered in building GNU Make without the macros?
|
Mon 12 Jul 2010 06:40:55 PM UTC, comment #1:
I'm not sure the best way to handle this. What's the triplet printed by running "config.guess" on your system?
|
Thu 26 Feb 2009 05:08:14 AM UTC, original submission:
Building GNU Make on Tru64 requires
CPPFLAGS = -D_XOPEN_SOURCE_EXTENDED -D_OSF_SOURCE
_XOPEN* is needed to get the prototype for bsd_signal(), and _OSF* to typedef u_long and friends, which is used in some system headers pulled in by getloadavg.c (and without said typedefs, the build breaks when compiling that file). I've confirmed that neither of these flags is made redundant by the other.
Please make a note of this in the documentation, or add appropriate logic to the configure script. I was able to determine the need for these flags, but other users might not.
|