Re: Patchless modification of Lua source code

[Sean Conner <sean@...>]

It was thus said that the Great Philipp Janda once stated:
> Am 23.11.18 um 06:47 schröbte Sean Conner:
> >
> >[...]
> >
> >	5.1.1.2:
> >
> >	8 All external object and function references are resolved.  Library
> >	  components are linked to satisfy external references to functions
> >	  and objects not defined in the current translation.  All such
> >	  translator output is collected into a program image which contains
> >	  information needed for execution in its execution environment.
> >
> >   I interpret this to mean, "if the given object files do not include an
> > object or function with external linkage, then said objects or functions
> > can be pulled from a "library".
> 
> Which library if there were multiple ones containing the same external 
> definition?

  I don't think that's covered in the C Standard.  I know that the C tool
chains I've used over the years have all defaulted to "seach each library,
in order specified on the command line" which seems a reasonable thing to
do.

> I interpret it differently. I think "translation" still means the
> translation of a single translation unit (i.e. a single object file) as in
> all other translation phases before. So you resolve as many undefined
> external references in the object file as you can using libraries, and the
> remaining ones are resolved from other compiled translation units when
> "all such translator output is collected into a program image".

  Okay, given this example:

	% cc -o program main.o other.o -lsomelibrary

  So, are you saying that during the linking phase, main.o is scanned first,
and any unresolved external references are scanned for in somelibrary to be
resolved, and then we move on to other.o and repeat the process?

  Huh ... I suppose that is a valid interpretation as well, even if I
haven't encountered a C compiler that does that (at least eight if I
recalled them all correctly).

> Btw., GNU ld is in violation of your interpretation of the C standard as 
> I have shown in one of my examples earlier (details here[99]):

  In my other email I covered this with both static and dynamic libraries. 
It was only in the case of a single translation unit containing all
functions where the link failed, which I think you would take as support for
your interpretation.  But the link succeeded when each function was in its
own translation unit in the library, which supports my interpretation (for
the two different tool chains I used).

  So who is correct here?

> Function `a()` shouldn't have been pulled from `libb.a` because `a.o` 
> already contains an external definition for that identifier.
> 
> GNU ld doesn't pull individual functions or objects from the library. It 
> just filters out those object files in the library that it thinks it 
> doesn't need.

  I think most linkers work this way.

  -spc

>   [99]:  http://lua-users.org/lists/lua-l/2018-11/msg00258.html