httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <BNICHO...@novell.com>
Subject Re: [PATCH] Apache 1.3.21-dev for NetWare builds (2, 3)
Date Fri, 03 Aug 2001 20:27:30 GMT
Pavel,
     The getch macro can be changed and checked in to exclude the parameters since the function
itself is a void.  The typedefs need to are required so you will problem just have to work
around them for now.  The inline problem is a little more difficult.  Does your compiler not
support inlined functions?  The code warrior comiler allows you to enable or disable the inline
functionality.  Are you sure that there isn't a compiler directive that will take care of
this problem?

thanks,
Brad

>>> novy@feld.cvut.cz Thursday, August 02, 2001 7:03:09 AM >>>
Hi,

> From:           "Brad Nicholes" <BNICHOLES@novell.com>

> Apache for NetWare doesn't actually use httpd.exp and the other 3
files are
> .imp files which are specific to the NetWare build.  So excluding the
patch
> for httpd.exp, they should be able to stay out of everybody else's
way.

I've reviewed my makefiles and found that this file is really unneeded
for these builds, so it can stay unchanged.

Brad, thanks for a quick fix in three NetWare related import(/export)
files - I've removed all those patches from my "GNU-build" package
recently.

*snip*

2. a _getch macro definition issue

If compiling with the GNU stuff, I am getting the following error:

src/ap/ap_getpass.c:149:34: macro `_getch' used without args
make: *** [src/ap/ap_getpass.o] Error 1

A "getch" function has no arguments: int getch(void);, so there is no
reason to have _getch macro defined with an argument. This macro is
defined in a "src/os/netware/os.h" by #define _getch(c) getch(c).
Changed to #define _getch getch, but #define _getch() getch() is
probably usable too.

3. redefinition of types issues

Not a problem with types (seen if compiling some 3rd party modules for
the Apache) but with some things defined by #define directive (it was a
bit inaccurate from me).

There are four things defined elsewhere in NDK and redefined in the
sources: FD_SETSIZE, S_ISLNK, opendir and readdir:

src/os/netware/os.h:116:22: warning: `FD_SETSIZE' redefined
./ndk/nwsdk/include/nlm/winsock/winsock2.h:95: warning: this is the
location of the previous definition
src/os/netware/os.h:123:20: warning: `S_ISLNK' redefined
./ndk/nwsdk/include/nlm/sys/stat.h:31: warning: this is the location of
the previous definition
src/os/netware/os.h:136:32: warning: `opendir' redefined
./ndk/nwsdk/include/nlm/dirent.h:80: warning: this is the location of
the previous definition
src/os/netware/os.h:140:32: warning: `readdir' redefined
./ndk/nwsdk/include/nlm/dirent.h:81: warning: this is the location of
the previous definition

These warnigs are displayed when any .c file with #include "os.h" is
compiled, so if redefinition is really needed (not sure for FD_SETSIZE
and S_ISLNK), I suggest to "#undef" first to omit these bothering
warnings (fortunatelly, it is not a reason for build failure).

Additionally, there is another problem with an "ap_os_is_path_absolute"
inline function defined in the same header file when linking the core
module (apachec.nlm):

src/ap/ap_snprintf.o: In function `ap_os_is_path_absolute':
src/ap/ap_snprintf.o(.text+0x1478): multiple definition of
`ap_os_is_path_absolute'
src/main/http_vhost.o(.text+0xe44): first defined here
src/buildmark.o: In function `ap_os_is_path_absolute':
src/buildmark.o(.text+0xc): multiple definition of
`ap_os_is_path_absolute'
src/main/http_vhost.o(.text+0xe44): first defined here
./nlmstuff/bin/nlmconv: Execution of ../nlmstuff/bin/ld failed

Not the best solution I am using by changing from "inline" to "static
inline", so if somebody find a better one...

---
I am currently not able to test it with CodeWarrior so I hope that Brad
or somebody else will do it. Patch for the "os.h" file resolving all
described issues is attached.

4. an uninitialized data issues
5. CodeWarrior bitfields alignment (compatibility) issue

These problems are more complex, so I plan to describe them in separate
postings.

Regards,
Pavel



Mime
View raw message