bugmake - Bugs: bug #13478, Missing include header for...


bug #13478: Missing include header for Microsoft, intel and Borland compiler

Submitter:  Jerker Bäck <jerker_back>
Submitted:  Mon 20 Jun 2005 04:29:23 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:  MS Windows
Fixed Release:  3.82 Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 30 Apr 2006 05:41:07 PM UTC, comment #6: 

If it's fixed let's close it.

I changed the config.h.W32 header to define HAVE_DIRECT_H in the situations you describe below, and changed make.h to use HAVE_DIRECT_H as the test for including direct.h, instead.

Paul D. Smith <psmith>
Group administrator
Sun 30 Apr 2006 04:14:04 PM UTC, comment #5: 

Paul, can we close this?
You added the direct.h which is fine. The issues with local CRT prototypes is entirely up to you. If they interfer with a compiler it is easy just to comment them out.

I would like to change the line which include direct.h to also support Interix. Like this:

make.h(358) /* This is needed for getcwd() and chdir().  */
make.h(359) #if defined(MSC_VER) || defined(__BORLANDC_)
make.h(360) # include <direct.h>
make.h(361) #endif

change to:
make.h(358) /* This is needed for getcwd() and chdir().  */
make.h(359) #if (defined(MSC_VER) || defined(__BORLANDC_)) && !defined(__INTERIX)
make.h(360) # include <direct.h>
make.h(361) #endif

Tested with MS compiler and Interix gcc - works fine.

The Interix SDK which is based on FreeBSD libc, do not have direct.h but is using the MS compiler. The proper conditional for Interix is __INTERIX (always defined for a interix build regardless of compiler used).

Thanks jerker

Jerker Bäck <jerker_back>
Sun 26 Jun 2005 10:55:01 PM UTC, comment #4: 

To get the code through a Win32 build with MSC and intel, we need to get the prototypes out. It's not a big deal really. You just need to decide what conditional to use.
My suggestion is: HAVE_ANSI_COMPILER for ANSI C issues and the
_WIN32 define for issues with the Win32 library. The good thing with _WIN32 is that it is always defined for any compiler targetting any Windows version. (note: _WIN32 not WIN32). There is no need to prepare anything, it's OK just to use it like this:

#if _WIN32
...Win32 library things

Why I say this is because the WINDOWS32 define used in make is not always consistent. So, in present code, whenever the _STDC_ is used, you will need to define WINDOWS32 as well. This is confusing because it has nothing to do with the Win32 library. To be portable it's better to use HAVE_ANSI_COMPILER and skip the _STDC_ and WINDOWS32 conditionals.

This will not work:
#if defined (_cplusplus) || (defined (__STDC_) && _STDC_)

but this will:
#if defined (_cplusplus) || (defined (__STDC_) && _STDC_) || defined (WINDOWS32)

as well as this:
#if defined (__cplusplus) || defined (HAVE_ANSI_COMPILER)

on the other hand this should never be allowed to work:
#if defined HAVE_UNISTD_H

could be used to indicate a UNIX-system

That's my thoughts

regards JB

PS: Details by bug reports on each issue

Jerker Bäck <jerker_back>
Sun 26 Jun 2005 04:03:19 PM UTC, comment #3: 

The reason I say including direct.h won't fix it is because we still define the prototypes: we need to not define them for MSC.

The problem is that on older UNIX systems, especially those which still provide headers dating back to K&R-style C compilers, many of the functions didn't have ANY prototypes in the header files.  And, the ones that were there usually didn't have any arguments specified in the header files.  In other cases, there were prototypes but they appeared in non-standard header files, which make authors didn't want to look for or include because they were too obscure.

The prototypes which appear in make.h are there to support systems like these.

I've pretty much decided that this release (3.81) will be the last release to support such old operating systems.  Starting with 3.82 I'm going to clean out all the support for pre-K&R compilers, and hopefully some of the hacks for "broken" compilers on various systems.  Most of the other GNU tools have already made this requirement and I would like to use some stuff from gnulib, etc. which I can't do today.  But, for 3.81 we'll have to muddle along as best we can without breaking too many existing things.

I'm going to release 3.81beta3 and so please take a look at that and see where we are: the main thing (now) holding up a 3.81 release is clarifying the DOS/Windows/OS/2/MINGW/MSC/etc. build issues.

Paul D. Smith <psmith>
Group administrator
Sun 26 Jun 2005 11:51:20 AM UTC, comment #2: 

Obviously the compiler need the prototypes in <direct.h>, which is the only system include file where these functions are declared. It is not a good solution to replace the prototypes with application defined ones.

Which leeds us to my mention about "bogus" prototypes. The compiler don't like them and do not need them. The whole idea of redeclare runtime functions seems very strange to me. I proposed two solutions which will satisfy the Microsoft compiler, but the issue is not mine. There is apparently someone who needs these prototypes (which compiler is that?) and a solution is better made by someone who knows what it is all about. I simply commented them out to succeed in my build.

make.h is not included in all source files. Is it not a good idea to move all conditionals and declarations to make.h and include make.h in all source files? I think project maintenance will benefit greatly in the long run on this.

regards Jerker

Jerker Bäck <jerker_back>
Sat 25 Jun 2005 10:57:39 PM UTC, comment #1: 

I added the <direct.h> include but I don't see how this will fix the problem.

Please provide more details... maybe a patch or two...

Paul D. Smith <psmith>
Group administrator
Mon 20 Jun 2005 04:29:23 AM UTC, original submission:  

When compiling with Microsoft or intel compiler using the Microsoft C runtime library, the following library functions are not declared: chdir, getcwd

They are declared in <direct.h> like this:
_CRTIMP int __cdecl _chdir(const char*);
_CRTIMP char* __cdecl _getcwd(char*, int);

Without direct.h make will define the following incorrect prototypes:
main.c(77):     extern int chdir ();
make.h(488):    extern char *getcwd ();

leading to at least fatal linking errors.

Add the following in make.h
#if defined(MSC_VER) || defined(__BORLANDC_)
#include <direct.h>

Related to this is also some (in this context) bogus prototype declarations at:
commands.c(36):     getpid
dir.c(1163):        stat
fnmatch.c(123)      getenv
getopt.c(209):      getenv
main.c(77):         chdir
main.c(834):        mktemp
make.h(289):        strerror
make.h(488):        getcwd
make.h(497):        environ
job.c(178):         dup2
job.c(179):         execve
job.c(180):         _exit
read.c(2922):       getenv

I suggest that these will be moved to make.h and protected with a conditional like:
#if defined(HAVE_GETENV) && defined(NEED_PROTOTYPE)
extern char *getenv ();

A solution could also be:
in the beginning of make.h
#ifdef  __cplusplus
extern "C" {

in the end of make.h
#ifdef  __cplusplus

regards Jerker

Jerker Bäck <jerker_back>


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by psmith (Updated 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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-07-28 psmith Fixed Release4.0 3.82
    2006-04-30 psmith StatusNone Fixed
        Assigned toNone psmith
        Open/ClosedOpen Closed
        Fixed ReleaseNone 4.0

    Back to the top

    Powered by Savane 3.13-7c56.
    Corresponding source code