Mailing-List: contact new-httpd-help@apache.org; run by ezmlm
Precedence: bulk
Reply-To: new-httpd@apache.org
From: "William A. Rowe, Jr." <wrowe@lnd.com>
To: <new-httpd@apache.org>
Subject: RE: [PROPOSED] linkage spec names, final binding vote
Date: Thu, 1 Jun 2000 09:35:37 -0500
Message-ID: <000c01bfcbd6$dd550640$345985d0@corecomm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-reply-to: <000801bfcbc6$5684a540$0200000a@gzunda>
Importance: Normal

> From: Tim Costello [mailto:timcostello@ozemail.com.au]
> Sent: Thursday, June 01, 2000 7:39 AM
> 
> What started my rant was me trying (just for fun) to compile 
> Apache on Win32 as a monolithic executable. Before anyone 
> complains that this would be a retrograde step, the things 
> involved are the same sorts of things that are involved if 
> we want to move functions (from a packaging perspective) 
> from the core to APR or vice versa. 

Solved, with /D API_STATIC (or APR_STATIC) in the compile flags.
And I already agree with you that a monolithic executable is a
good thing, for certain servers config'ed for specific purposes.

> A more dramatic move would be to split APR's binary package 
> on windows into 
> multiple libraries, one for network i/o, one for file i/o, 
> etc. At the 
> moment, that's just not possible - to make it possible, there'd be a 
> significant effort involved in getting the declspecs correct 
> for callers 
> and callees. If the current model were extended - a macro to 
> indicate if 
> we're inside, and macros specific to the package that either 
> dllimport or 
> dllexport, then we'd end up with a plethora of macros that 
> did similar 
> things (and probably with similar names). This is just an 
> example - more 
> probable is moving single functions from core -> apr and vice versa. 

OK... gotcha :-)

Your solution: write a bunch of .def's based on how you will link
each part of the package.  Breaks every time someone commits a
new function to code. :<(  Further you aren't telling the compiler
what the end product is.

My proposal six weeks from now will be to drop .def files altogether.
Each module identifies it's exports, so mix and match and you have 
multiple dynamic libraries.  Someone commented that M$'s hashing of
the DLL's symbol names makes the ordinal/named linkage issue nearly
mute.  But that doesn't solve our problem that you address.  Why?

It isn't the EXPORT tags in the .c modules, those are already
just fine.  It's the declares in the headers... they identify 
every import as an export.  Whatever sources you built and linked
would be exported.  But that's not the whole problem.

It also would attempt to export every other symbol in the package,
since the headers those modules loaded identify linked functions
that they claim to be exported from this same dynamic library.
The simple solution?  Every header declaration becomes an import.
But we still have a conflict... we are then linking _every_ function 
in the dynamic library that is outside of the current module through 
the export table.  Not clean, and a link warning we can't #pragma 
away.

Not one of the solutions thus far addresses this issue, not your's,
not mine, not the libraries.  If you want pure explict .def fixups,
as in your monolith, use APR/API_STATIC.  If you want the right 
solution, long term, we haven't proposed one have one yet :-)

I'm open to ideas once the mpm and services are stable and tested,
and we have Win95 serving (not serving well, just serving.)  But
the solution you propose is no solution, IMHO.

> In summary - let linkage issues be dealt with by the linker, 
> not by compiler directives. 

If this had no impact on the machine code I would agree.  
Unfortunately, that isn't the case.

> wow - I'm impressed. I didn't even realise I was talking about calling
> conventions :-)

Neither did I on the first read ;-)
 
> > If anyone wants APR (__cdecl) or apache (__stdcall)
> > toggled, speak up.  I was considering some benchmarks of
> > both __cdecl, and both __stdcall, but I'm not there yet.
> 
> My only opinion on this one is that we should be consistent. I didn't
> realise we had different default conventions for the core and 
> for APR. Is there a reason?

Actually, apr isn't a 'subset' of apache, it's core functions that
(in theory) often wouldn't be implemented by a high level client, but
I do in fact agree with you.  The reason?  History, and the original
files I'd been working with (both the draft Win32 APR and ApacheCore).