apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gisle Vanem" <g...@bgnett.no>
Subject Re: Inline problems on MingW
Date Mon, 30 Aug 2004 16:51:16 GMT
Sorry for the late reply,

"Cliff Woolley" <jwoolley@virginia.edu> wrote:

> That said, APR does build on cygwin (or at least it used to at some
> distant point in the past), so I see no reason why it shouldn't be made to
> build on mingw.

I have attempted some Cygwin hacking, but prefer MingW for it's runtime
speed (-tune=pentium rivals MSVC6 with all optimise flags on).

> Feel free to submit those patches, appropriately #ifdef'ed so that they
> won't break the msvc build (or if you submitted them already and we missed
> them, please give us a pointer to them again).

Okay, I worked on the original problem and found a viable fix; Leave the
APR_INLINE in apr.hw as-is:

#define APR_INLINE __inline

But in headers like arch\win32\apr_arch_atime.h, with inline code do at

#ifdef __GNUC__
#undef  APR_INLINE
#define APR_INLINE extern __inline

APR_INLINE void FileTimeToAprTime(apr_time_t *result, FILETIME *input)
at bottom:

#ifdef __GNUC__
#undef  APR_INLINE
#define APR_INLINE __inline

"extern __inline" is the only usable form AFAICS gcc will work with. Otherwise
we'll get bloated .o-files and possibly duplicate symbol errors when linking
the DLLs. I don't know the gcc details.

But IMO the best would to do:

#ifdef __GNUC__
  extern __inline
  APR_INLINE  /* whatever this is */
void FileTimeToAprTime(apr_time_t *result, FILETIME *input)

What way do you prefer? I need to hear comments on this before I
commit any MingW patches.

Another problem is that "extern __inline" code will *not* be inlined with
"gcc -O0" (__NO_INLINE__ becomes a built-in). So a gcc-built DLL must
use -O1 or higher unless we "sweep up" such inline functions in a src-file.

BTW. Could we please have a bit more intuitive suffixes to the
config-files? I.e. apr.h.netware, apr.h.win32 etc. Just my 0.2€


View raw message