bugmake - Bugs: bug #25713, Please note CPPFLAGS required to...

 
 

bug #25713: Please note CPPFLAGS required to build on Tru64

Submitter:  Daniel Richard G. <iskunk>
Submitted:  Thu 26 Feb 2009 05:08:14 AM UTC
   
 
Severity:  3 - Normal Item Group:  Build/Install
Status:  Fixed Privacy:  Public
Assigned to:  psmith Open/Closed:  Closed
Component Version:  4.0 Operating System:  POSIX-Based
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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:


targets/ONESHELL ........................................ ok     (5 passed)
targets/PHONY ........................................... ok     (1 passed)
targets/POSIX ........................................... Error running /tmp/make-3.81.91/__build__/tests/../make (expected 512; got 0): /tmp/make-3.81.91/__build__/tests/../make -f work/targets/POSIX.mk
FAILED (0/2 passed)
targets/SECONDARY ....................................... ok     (12 passed)
targets/SILENT .......................................... ok     (1 passed)
[...]
variables/MFILE_LIST .................................... ok     (1 passed)
variables/SHELL ......................................... Error running /tmp/make-3.81.91/__build__/tests/../make (expected 512; got 0): /tmp/make-3.81.91/__build__/tests/../make -f work/variables/SHELL.mk.6
FAILED (6/7 passed)
variables/automatic ..................................... ok     (7 passed)
variables/define ........................................ ok     (15 passed)


Are these a cause for concern?

Daniel Richard G. <iskunk>
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.

Paul D. Smith <psmith>
Group administrator
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:


configure:7340: checking for bsd_signal
configure:7340: cc -std -o conftest -g   conftest.c  >&5
configure:7340: $? = 0
configure:7340: result: yes


(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:


source='../getloadavg.c' object='getloadavg.o' libtool=no  DEPDIR=.deps depmode=tru64 /usr/home/cport/tmp/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   -D_XOPEN_SOURCE_EXTENDED  -g -c ../getloadavg.c
cc: Error: /usr/include/sys/mbuf.h, line 182: Missing type specifier or type qualifier. (missingtype)
        u_int        ext_size;                /* size of buffer, for ext_free */
--------^
cc: Error: /usr/include/sys/mbuf.h, line 417: Missing type specifier or type qualifier. (missingtype)
        u_long        m_mbufs;        /* obsolete: tracked by malloc M_MBUF stats */
--------^
cc: Error: /usr/include/sys/mbuf.h, line 418: Missing type specifier or type qualifier. (missingtype)
        u_long        m_clusters;        /* obsolete: tracked by malloc M_CLUSTER stats*/
--------^
cc: Error: /usr/include/sys/mbuf.h, line 419: Missing type specifier or type qualifier. (missingtype)
        u_long        m_drops;        /* times failed to find space */
--------^
cc: Error: /usr/include/sys/mbuf.h, line 420: Missing type specifier or type qualifier. (missingtype)
        u_long        m_drain;        /* times drained protocols for space */
--------^
cc: Error: /usr/include/sys/mbuf.h, line 421: Missing type specifier or type qualifier. (missingtype)
        u_int        m_mtypes[MT_MAX];        /* obsolete: tracked by MALLOC(type) stats */
--------^
[several more such errors elided]
cc: Severe: More than 30 errors were encountered in the course of compilation. (toomanyerr)
*** Exit 1
Stop.
*** Exit 1
Stop.
*** Exit 1
Stop.


As originally reported, adding "#define _OSF_SOURCE" does the trick.

(file #20969)

Daniel Richard G. <iskunk>
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!

Paul D. Smith <psmith>
Group administrator
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)

Daniel Richard G. <iskunk>
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.

Paul D. Smith <psmith>
Group administrator
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);
--^
* Exit 1 (ignored)
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)
* Exit 1 (ignored)

Daniel Richard G. <iskunk>
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.

Paul D. Smith <psmith>
Group administrator
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?

Daniel Richard G. <iskunk>
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?

Paul D. Smith <psmith>
Group administrator
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.

Daniel Richard G. <iskunk>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #20969:  signal.h added by iskunk (24KiB - text/x-chdr - Tru64 system header file)
file #20949:  config.h added by iskunk (13KiB - text/x-chdr - Requested files from Tru64 system)
file #20950:  bsd_signal.man added by iskunk (2KiB - application/x-troff-man - Requested files from Tru64 system)
file #20951:  main.i added by iskunk (125KiB - application/octet-stream - Requested files from Tru64 system)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  • -email is unavailable- added by iskunk (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2010-07-19 psmith Item GroupDocumentation Build/Install
        StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Operating SystemNone POSIX-Based
        Fixed ReleaseNone 4.0
    2010-07-14 iskunk Attached File- Added signal.h, #20969
    2010-07-13 iskunk Attached File- Added config.h, #20949
        Attached File- Added bsd_signal.man, #20950
        Attached File- Added main.i, #20951

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code