Re: Esound 0.2.8 is dead - Esound 0.2.23 compiles fine

[Christopher Faylor <cgf at redhat dot com>]

On Sun, Oct 28, 2001 at 07:09:24PM -0500, Charles Wilson wrote:
>Robert Collins wrote:
>>Chuck: A suggestion for ld if it's feasible: Detect auto-exported
>>variables that can't be auto-imported and warn about them. This will
>>save guesswork or laborious source code auditing for new ports.
>>
>>I haven't looked at the auto-import stuff since the work we did months
>>ago - does this sound feasible to you?
>
>I don't think so.  The way we recognize the problematic imports not 
>proactive, it's reactive.  When gcc compiles an object with an import 
>reference to a "bad" variable type, it creates an offset addend.  We SEE 
>that nonzero addend, and flag it as an error -- but you only see that when 
>trying to link the *calling* object; you don't see that funky addend stuff 
>when linking the *providing* object (the DLL itself).
>
>AFAIK, there's nothing special about the export itself (except that it 
>requires multiple words for storage) that we can recognize proactively when 
>building the DLL itself.  (Anything based on subtracting the base addresses 
>of "consecutive" exports is bound to be flaky).

Ah.  I was wondering why errors weren't bein displayed already.  Now I
understand the distinction.

If we added a "--warn-bad-auto-export" as an ld option for building
DLLs, could we flag errors that way?  Would it give false negatives if
we warned about multi-word exports?

cgf