apr-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r434327 - in /apr/apr/trunk: CHANGES include/arch/win32/apr_arch_threadproc.h misc/win32/start.c threadproc/win32/threadpriv.c
Date Fri, 17 Nov 2006 11:50:34 GMT
Mladen Turk wrote:
> Since all this is a hack, IMHO we can simply exploit the
> feature from DLL apr build, and leave the current
> status for LIB builds like it was before.
> (BTW, my patch does that).

Given the choice between supporting all architectures except amd64, or
supporting only .dll's, I vote for the former.  That's -1 to the code
living in trunk.

The DLL thing is a 'hack' - something that doesn't solve the whole issue
but works around the problem in front of you.  The CRT linkage is by design
in the PE format, the only hacks needed are to resolve why certain PE flavors
are being handled differently than others, and writing the #if arch logic
to handle this or leave it unresolved for an architecture.

Native-64 is going to seriously underperform 32 bit compilations for 95% of
applications in the first place.  But it's entirely reasonable (and common)
for developers to decide to roll out a monolithic .exe binary.

Other opinions before Mladen or I proceed?

View raw message