[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Query on linking order
From: |
Gaius Mulley |
Subject: |
Re: Query on linking order |
Date: |
Tue, 04 Jul 2023 13:25:05 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) |
john o goyo <jog37@riddermarkfarm.ca> writes:
> Greetings, Gaius.
>
> On 2023-07-03 14:32, Gaius Mulley wrote:
>> john o goyo <jog37@riddermarkfarm.ca> writes (in part):
>>
>>> [...]
>>>
>>> It seems that gm2 tries to include the IO.mod is the current
>>> directory, despite no directive to do so.
>>>
>>> I could not find anything relevant in the gm2 documenation.
>>>
>>> Please advise.
>> Hi John,
>>
>> to clarify - from the user linking perspective - it is safer to consider
>> the gm2 modula-2 universe requiring distinct module names
>>
>> regards,
>> Gaius
>
> Noted.
>
> As also noted by Michael, the gm2 linker moves on if a module of the
> same name is renamed or placed in a different directory.
>
> Sincerely,
> john
Hi John,
I'm looking deeper at the problem - I'm wondering if it could be
considered a bug when using the default -fscaffold-dynamic linking as it
should have no need to parse all the modules. For the -fscaffold-static
case it does need to parse the modules to determine the import graph
tree for the application - but the downside then is that we could have a
project able to be linked by -fscaffold-dynamic and not with
-fscaffold-static :-)
Also worth noting is that if you are generating libraries you can have
modules with the same name (Storage and SYSTEM are prime examples).
The iso and pim libraries utilise this feature - and use named paths
which are prefixed to the symbol in any exported identifier. The user
still as to decide which variant of library they require of course.
The named path allows for all libraries to be linked without depending
upon linker path ordering
regards,
Gaius