httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David D'Antonio" <...@individual.com>
Subject RE: another naming question
Date Mon, 29 Dec 1997 18:35:20 GMT
On Sunday, December 28, 1997 10:07 AM, Rodent of Unusual Size 
[SMTP:Ken.Coar@Golux.Com] wrote:
> Alexei Kosut wrote:
> >
> > Now, if I upgrade Apache to a new version, which has a brand new rfoo()
> > function, rprintf() will now be number 43 (VC++ alphabetically sorts its
> > exported symbols). If I try and link that same DLL in, instead of pointing
> > to rprintf(), function 42 will now be rputs() or something.
>
> Ewwwww!  That is *so* brain-damaged!  Can VC++ be convinced to *not*
> sort the symbols?  Otherwise it sounds like the whole motivation for
> your proposals is to make Apache work in an environment that uses
> technology and methodologies at least two decades out of date.  Which
> I don't consider worthy of making a priority.  Trying to make it work in
> a manner a little closer to the current century's practices (such as
> considering symbol ordering sequences invariant) I can accept.  But
> if VC++ always sorts the symbols.. ugh!

I checked through all the options in the linker (as given in the VC++ help)
and they have a couple which look interesting. One is /FORCE which forces
the program to link in spite of unresolved/multiply defined symbols.

Another is /IMPORT: which has a number of options to say which symbols
should be imported from which "containers" (LIB files) and what versions of
both code and API are compatible!

The last is /ORDER which takes a filename specifying the order of COMDATs
(functions ?) to be put into the image. But you have to compile your modules
with /Gy to get COMDATs. This also "enables function level linking."

So it appears that VC++ can be massaged into doing some things correctly.

As for OpenVMS and its shared library "versioning" scheme, I can say that it
has caused me numerous troubles over and over. It seems that folks will often
link against the "latest" version on their system, despite the fact that their 
program
doesn't USE anything in the "latest" version. It would run just fine on several 
previous
versions. But the system DEMANDS that that version (or later) be available. So 
the
image doesn't run.

My other complaint is that the error message generated isn't very clear about 
what
the problem is and how to fix it.

On the other hand, it is FAR better to get an error than to have the thing go 
off and
use the wrong library and do something wierd.

> #ken	P-)}

DDA

--
David D'Antonio CNE - dda@SpamBeGone.individual.com
 Some they do and some they don't and some ya just can't tell
  Some they will and some they won't and some it's just as well
						-SuperTramp



Mime
View raw message