Bug #1923

Compilation on AIX

Added by cstup almost 6 years ago. Updated over 5 years ago.

Status:Missing FeedbackStart date:2009-03-02
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:1.4.23
Missing in 1.5.x:

Description

Compiling 1.4.21 on AIX5.3, with the native compiler. A few issues come up.

If HAVE_FAM_H isn't defined, then STAT_CACHE_ENGINE_SIMPLE has a enum member with a trailing comma, which is not allowed in ANSI C.

src/base.h 493:
        enum { STAT_CACHE_ENGINE_UNSET,
                        STAT_CACHE_ENGINE_NONE,
                        STAT_CACHE_ENGINE_SIMPLE,
#ifdef HAVE_FAM_H
                        STAT_CACHE_ENGINE_FAM
#endif

C++ comments are not permitted in ANSI C.

src/mod_evasive.c 
147c147
<               default: /*  Address family not supported */
---
>               default: // Address family not supported

In src/network_writev.c, "network_backends.h" is being included before all the system includes, which causes O_LARGEFILE to be attempted to be refined by the system includes.

Theres an issue with the struct member "mmap" in chunk.h. AIX has the following in sys/mman.h:

#ifdef _LARGE_FILES
#define mmap    mmap64
#endif  /* _LARGE_FILES */

Theres an odd conflict when compiling mod_webdav.c, where the symbol appears to be "mmap" in chunk.h, but when compiling mmap references in mod_webdav, its being redefined as mmap64.

It might be cleaner to not use a runtime function as a struct member? I can dig deeper to see the conflict...

The UNUSED functions appear to try and remove them for lint checking, but don't exist on AIX.
"mod_ssi_exprparser.c", line 782.3: 1506-046 (S) Syntax error.
The issue also exists in configparser.c, same generated function.

mod_ssi_exprparser.c (yy_syntax_error)
780a781,782
>   UNUSED(yymajor);
>   UNUSED(yyminor);

ANSI C/cpp doesn't seem to like the #ifdef in the middle of a function.

configfile.c:
1009d1008
<       pos = strrchr(fn,
1011c1010
<                       '\\'
---
>       pos = strrchr(fn, '\\');
1013c1012
<                       '/'
---
>       pos = strrchr(fn, '/');
1015d1013
<                       );

With these changes, I was able to get it compiled with the native compiler. A -V dump shows the following:

lighttpd-1.4.21 - a light and fast webserver
Build-Date: Mar  2 2009 16:06:02

Event Handlers:

        + select (generic)
        + poll (Unix)
        - rt-signals (Linux 2.4+)
        - epoll (Linux 2.6)
        - /dev/poll (Solaris)
        - kqueue (FreeBSD)

Network handler:

        + writev
        + mmap support

Features:

        + IPv6 support
        + zlib support
        + bzip2 support
        + crypt support
        - SSL Support
        + PCRE support
        - mySQL support
        - LDAP support
        - memcached support
        - FAM support
        - LUA support
        - xml support
        - SQLite support
        - GDBM support

I'll have to test more of the modules shortly, and run some of the tests.

Associated revisions

Revision 2408
Added by stbuehler almost 6 years ago

Fix some problems with more strict compilers (#1923)

Revision 2440
Added by stbuehler over 5 years ago

Include mmap.h from chunk.h to fix some problems with #define mmap mmap64 (fixes #1923)

Revision 2465
Added by stbuehler over 5 years ago

merge: Include mmap.h from chunk.h to fix some problems with #define mmap mmap64 (#1923)

History

#1 Updated by stbuehler almost 6 years ago

  • Please use "diff -u" for creating diffs
  • mmap problem:

It might be cleaner to not use a runtime function as a struct member? I can dig deeper to see the conflict...

This is something i don't like. Sure, we could rename mmap to "my_mmap" or something else. But how can we be sure there will be no #define my_mmap my_mmap64?
Imho no platform should use such defines (even #define mmap(param, list) mmap64(param, list) isn't safe); using static inline functions should be the right thing.

But i think we can fix this if we add #include "sys-mmap.h" in chunk.h after line 5 ("array.h"); it would be nice if you could test this.
  • The other problems should be fixed in the next commit.

Thx!

#2 Updated by stbuehler almost 6 years ago

  • Target version set to 1.4.23

#3 Updated by cstup almost 6 years ago

Sorry about the diff issue. I was just kinda throwing it together and wasn't paying attention to old/new either. I'll make sure to be more consistant (and use diff -u) next time. The -u option is a GNU diff thing which AIX doesn't support by default, so I usually forget.

I'm not sure how I feel about the mmap() thing either. I agree with you that its goofy the system has a #define based remapping (no pun intended) of the symbol, but OTOH it might also be considered poor form to use a function name as a struct member. At best, it was a bit confusing to see mmap as a nested struct member to the uninitiated.

A crappy compile time hack might be something like:

#if defined(_AIX) && defined(mmap)
#error compile time assertion, mmap has been redefined
#endif

At least that would point it out on future AIX builds...

I'll be happy to test the chunk.h change shortly. I'll report my findings.

Thanks!

#4 Updated by stbuehler over 5 years ago

  • Status changed from New to Missing Feedback

#5 Updated by cstup over 5 years ago

Sorry for not updating the ticket. The change adding sys-mmap.h chunk.h fixes the issue, as expected. As long as the same redefines occur consistantly, we're okay.

chunk.h:
#include "buffer.h"
#include "array.h"
#include "sys-mmap.h"

Thanks!

Also available in: Atom