lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Le jeu. 22 nov. 2018 à 07:53, Philipp Janda <> a écrit :
Am 21.11.18 um 12:12 schröbte Luiz Henrique de Figueiredo:
>> The linker will search an archive only once, at the location where it
>> is specified on the command line. If the archive defines a symbol
>> which was undefined in some object which appeared before the archive
>> on the command line, the linker will include the appropriate file(s)
>> from the archive.
So it seems to work in practice on Linux using my current version of the
GNU linker if the original object file is in an archive, the modified
object file is listed before the archive on the command line, and the
modified object file exports at least all the same symbols as the
original object file.

This does not contradict what I said: having a priority order does not mean that a "past" library will necessarily be read again: the linker just needs to keep it (at least partly: the minimum is its table of symbols and the module in which it is defined). Then it still resolved the symbols from the set of "active" modules in order to determine the list of modules to keep, and assemble new ones until there remains no unresoved symbols, but any module that does not define any needed symbol for the assemblee can be dropped from the assemblee (only its list of external symbols is kept); if there remains unresolved symbols, the linker can only generate a partially linked module (containing all their exported symbols). In all cases, the priority order is preserved. But not all specifiied modules will be packed together in the assemblee, but only what is needed (and notably not the full set of unneeded modules that are packed in a library). The exception is when building a library (all modules are kept), or a shared library (only modules that contain exported symbols are kept along with their dependant modules definining non-exported symbols needed by other modules).
If the result of linking must be an executable or a shared library, the link will fail if there remains unresolved symbols, or what will be produced will be a file in a intermediate object format which is not executable, and contains the list of unresolved symbols (because such format may still allow later binding in a next pass of the linker)