GSOC Linker project

[Steven Schveighoffer]

On Mon, 07 May 2012 13:34:49 -0400, Andrew Wiley  
<wiley.andrew.j at gmail.com> wrote:

> On Mon, May 7, 2012 at 12:21 PM, Steven Schveighoffer
> <schveiguy at yahoo.com>wrote:
>
>>
>> I agree that's the case with the current object/linker model.  Something
>> that puts inferred properties into the object file needs a new model,  
>> one
>> which does not blindly link code that wasn't compiled from the same  
>> sources.
>>
>
> Then all you've done is to make attributes the author can't control part  
> of
> the API, which will force library users to recompile their code more  
> often
> for non-obvious reasons. Avoiding that is one of the points of shared
> libraries.

Shared library entry points have to have *no* inference.  Otherwise you  
could inadvertently change the public API without explicitly tagging it.

I believe in D, shared library entry points have to be tagged with export.

Not to mention, shared libraries on a certain platform usually have to be  
linked by the platform's linker.  So we can't exactly overtake that aspect  
with a new model.

>
> I think we're actually talking about different contexts. I'm speaking in
> the context of shared libraries, where I think the API needs to be  
> exactly
> what the author requests and nothing more. With object files, static
> libraries, and static linking, I agree that this sort of thing could work
> and wouldn't cause the same problems because it's impossible to swap the
> library code without recompiling/relinking the entire program.

OK, that makes sense, I think you are right, we were talking about two  
different pieces of the model.

-Steve