Re: Query on linking order

[Gaius Mulley]

john o goyo <jog37@riddermarkfarm.ca> writes:

> Greetings, Michael.
>
> On 2023-07-02 18:04, Michael Riedl wrote:
>> John, Gaius,
>>
>> that looks quite similar to an observation I made when linking "C"
>> code with a "normal" definition module (no 'FOR "C"' clause) and I 
>> also had an implementation module in the subdir with a corresponding
>> name (e.g. foo.def, foo.c foo.o (compiled out of foo.c) and foo.mod) 
>> and and "IMPORT foo" in the main module. OK - here I "fooled" the
>> linker by mistake (though giving foo.o explicitly in the argument
>> list for the linker), so renaming foo.mod e.g. to foo.mi fixed the
>> issue.
>>
>> Maybe also related to issue with the linking of my bigger programs I
>> reported quite a while ago.
>>
>> The linker "walks" though all implementation modules and makes
>> nonsense if this is too much code (in my huge sample it claimed
>> errors where there where non) or imports even unused code.
>>
>> In Johns sample I would assume there was an import of "IO" somewhere
>> in dependency tree - if I rename IO.{def|mod} to IOlocal.{def|mod}
>> the error vanishes.
>
> Yes, m2/m2pim/StdIO.mod imports m2/m2pim/IO.mod but my local IO.mod is
> imported instead.
>
>>
>> Gruß
>>
>> Michael
>>
>> PS: John, your error is reproducible on an Linux/Intel machine
>
> Thank you for testing on your machine.
>
> Sincerely,
> john
>
>>
>> ---------
>>
>> mriedl@laptop:~/Modula-2/GM2/John$gm2 -c -fscaffold-main first.mod
>> ./IO.mod:10:5: Warnung: In procedure »Something«: syntax warning,
>> »END« missing
>>    10 | END Something;
>>       |     ^~~~~~~~~
>> /usr/local/gm2-13.1.0/bin/../lib/gcc/i686-pc-linux-gnu/13.1.0/./m2/m2pim/StdIO.mod:163:18:
>> Fehler: In implementation module »StdIO«: unknown ident in the 
>> construction of a qualident
>>   163 |    PushOutput(IO.Write) ;
>>       |                  ^~~~~
>> /usr/local/gm2-13.1.0/bin/../lib/gcc/i686-pc-linux-gnu/13.1.0/./m2/m2pim/StdIO.mod:164:17:
>> Fehler: unknown ident in the construction of a qualident
>>   164 |    PushInput(IO.Read)
>>       |                 ^~~~
>> mriedl@laptop:~/Modula-2/GM2/John$
>>
>> --------
>>
>> Am 02.07.23 um 20:01 schrieb john o goyo:
>>> Greetings, Gaius.
>>>
>>> What is the linking order for gm2?
>>>
>>> Reason: When linking, it seems that gm2 looks in the current
>>> directory even though there is no reference to the current
>>> directoy.
>>>
>>> Example: Note the following sequence.
>>>
>>> [~/prj/tst]=> cat first.mod
>>> MODULE first;
>>>
>>>    FROM InOut IMPORT WriteString, WriteLn;
>>>
>>> BEGIN
>>>    WriteString("Modula-2. What else?"); WriteLn;
>>> END first.
>>>
>>> [~/prj/tst]=> cat IO.def
>>> DEFINITION MODULE IO;
>>>
>>> (*
>>>  * Test module for gm2 linking order.
>>>  *)
>>>
>>> PROCEDURE Something(i :CARDINAL) :CARDINAL;
>>>
>>> END IO.
>>>
>>> [~/prj/tst]=> cat IO.mod
>>> IMPLEMENTATION MODULE IO;
>>>
>>> (*
>>>  * Test module for gm2 linking order.
>>>  *)
>>>
>>> PROCEDURE Something(i :CARDINAL) :CARDINAL;
>>> BEGIN
>>>   IF ODD(i) THEN RETURN i + 1
>>> END Something;
>>>
>>> END IO.
>>>
>>> [~/prj/tst]=> gm2 -c first.mod
>>> [~/prj/tst]=> gm2 first.mod
>>> ./IO.mod:10:5: warning: In procedure : syntax warning,  missing
>>>    10 | END Something;
>>>       |     ^~~~~~~~~
>>> /home/build/gcc/13.1.0/lib/gcc/sparc-sun-solaris2.11/13.1.0/m2/m2pim/StdIO.mod:163:18:
>>> error: In implementation module : unknown ident in the construction 
>>> of a qualident
>>>   163 |    PushOutput(IO.Write) ;
>>>       |                  ^~~~~
>>> /home/build/gcc/13.1.0/lib/gcc/sparc-sun-solaris2.11/13.1.0/m2/m2pim/StdIO.mod:164:17:
>>> error: unknown ident in the construction of a qualident
>>>   164 |    PushInput(IO.Read)
>>>       |                 ^~~~
>>>
>>>
>>> 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.
>>>
>>> Sincerely,
>>> john

Hi John and Michael,

the -fsources option might help as it displays the source file location
and whether the source is used to resolve linking.  It should show the
module name conflict (indirectly) and it will follow the -I search path
order.  The modulename [namedpath] might be interesting as the namedpath
(m2pim or m2iso or m2log) are system installed libraries whereas user
modules will likely have []).

Once the application has linked it might be worth enabling the trace env
variable when running the application:

$ export GCC_M2LINK_RTFLAG=all
$ ./a.out

which will display each module as it registers itself with M2RTS and
then the order of initialization (determined by the import call graph)

p8 in gm2.pdf contains an example

regards,
Gaius