httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Costello <timcoste...@ozemail.com.au>
Subject RE: [PROPOSED] linkage spec names, final binding vote
Date Thu, 01 Jan 1970 00:00:00 GMT
On Thursday, 01 June 2000, William A. Rowe, Jr. wrote:
> 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.

but.... I wasn't saying that! I was just suggesting that it would be good if
you could move code from package to package easily. Easily to me is only
having to change linker commands (ie. the DEF files) - not any source files. 

..
> 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.

Yes and maybe. It'll only break things when there's a function added that
people need to access from outside the package (whatever that happens to
be). Plus, it only breaks Windows - and the fix is really simple! We don't
have to constantly be on people's backs about adding macros that are 
defined away to nothing on most (all?) other platforms - a la the recent I/O
filtering patch. 

..
> 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.

hang on - you mean every function in the dynamic link library - don't you? 
What is the "current module"?

WRT the warnings - can't and shouldn't. We'd be forcing the compiler to 
generate indirect calls when it should be generating direct ones. 

> 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 missing something. If the issue is making indirect calls regardless of
the actual location of a function, use of import libraries does address the
issue. Indirect calls are only ever made if something lives in a DLL, and 
the caller doesn't, and you've linked against its import library. Otherwise 
it's a direct call. What was the issue you were talking about?

Oh, and there's no need for indirect calls / fixups in the monolith. All
symbols are locally defined. :)

> 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.

It depends what the problem is. My problem - difficult to move code from one
package to another. Solution - use only linker directives for linking. The 
only downside I can see is that you get thunks. To understand your thinking 
- do you find thunks (an additional JMP per function call) unacceptable? 

(i'm thinking you'll say "yes", in which case this thread should probably
die). 

..
> > 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).

I was referring to the package formerly known as "apachecore" (=>
apachecore.dll), and apr (currently living in apr.lib and aprlib.dll). 

Cool. Can we change it to be the same? don't mind which. don't mind doing
the patch.

Tim

This message was sent through MyMail http://www.mymail.com.au



Mime
View raw message