Sorry for the late reply,
"Cliff Woolley" <[EMAIL PROTECTED]> 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
top:
#ifdef __GNUC__
#undef APR_INLINE
#define APR_INLINE extern __inline
#endif
APR_INLINE void FileTimeToAprTime(apr_time_t *result, FILETIME *input)
{
...
}
at bottom:
#ifdef __GNUC__
#undef APR_INLINE
#define APR_INLINE __inline
#endif
"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
#else
APR_INLINE /* whatever this is */
#endif
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â
--gv
