Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

>> gm2.texi.  I see a few missing options (missing from gm2.texi) and also
>
> Do you have an example, please?

-fscaffold-main was missing from gcc/doc/gm2.texi.  I've git pushed a
 correction (and alphabetically sorted all options).

>> I see problems with the libraries - meta data (const/type/var) is
>
> What type of meta data do you mean?

@findex functionname [meta]

for an example see:

builddir/gcc/m2/gm2-libs.texi

(* all the following types are declared internally to gm2
TYPE
@findex LOC (type)
   LOC ;

@findex ADR
PROCEDURE ADR (VAR v: ): ADDRESS;
  (* Returns the address of variable v.  *)

The above findex populates the function index and is issued at the end
of m2/doc/gm2.texi by a call to:

@printindex fn

An example output:

https://www.nongnu.org/gm2/12/functions.html
More detail on findex
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Predefined-Indices.html

hope this is useful,

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 9/8/22 17:52, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> Note I've just converted the current Modula-2 manual to RST (Sphinx):
>> https://splichal.eu/scripts/sphinx/
>>
>> It contains some minor issues, but in general it should be pretty fine. Note 
>> pygments
>> contains a corresponding lexer:
>> https://pygments.org/docs/lexers/#multi-dialect-lexer-for-modula-2
> 
> very nice - well done!  All very useful - and much easier to see bugs in
> gm2.texi.  I see a few missing options (missing from gm2.texi) and also

Do you have an example, please?

> I see problems with the libraries - meta data (const/type/var) is

What type of meta data do you mean?

> rendered (@findex perhaps should be ignored or processed).  Or I could
> disable it from gcc/m2/tools-src/def2texi.py)?
> 
> It is starting to look very nice indeed

Thanks!

Martin

> 
> regards,
> Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

> Note I've just converted the current Modula-2 manual to RST (Sphinx):
> https://splichal.eu/scripts/sphinx/
>
> It contains some minor issues, but in general it should be pretty fine. Note 
> pygments
> contains a corresponding lexer:
> https://pygments.org/docs/lexers/#multi-dialect-lexer-for-modula-2

very nice - well done!  All very useful - and much easier to see bugs in
gm2.texi.  I see a few missing options (missing from gm2.texi) and also
I see problems with the libraries - meta data (const/type/var) is
rendered (@findex perhaps should be ignored or processed).  Or I could
disable it from gcc/m2/tools-src/def2texi.py)?

It is starting to look very nice indeed

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 8/31/22 15:25, Martin Liška wrote:
> On 8/31/22 15:19, Gaius Mulley wrote:
>> Martin Liška  writes:
>>
>>> How do you mean that? You should ideally generate .rst (Sphinx markup)
>>> instead of the *.texi files. These will be then included in the converted
>>> Sphinx manual similarly to how you include it now to the Texinfo manual.
>>>
>>> Does it make sense?
>>>
>>> Cheers,
>>> Martin
>>
>> ah right - yes this makes sense.
> 
> Goo!
> 
>> I mistakenly thought the .rst files
>> could be automatically generated from texinfo sources.  In any case
>> generating .rst directly will likely contain advantages,
> 
> Yes, that's what I'm doing for the existing documentation, but the conversion
> is not perfect and I had to make some manual changes to the emitted .rst 
> content.
> 
> So please fix the crash I reported and I can convert GM2 texi manual.

Note I've just converted the current Modula-2 manual to RST (Sphinx):
https://splichal.eu/scripts/sphinx/

It contains some minor issues, but in general it should be pretty fine. Note 
pygments
contains a corresponding lexer:
https://pygments.org/docs/lexers/#multi-dialect-lexer-for-modula-2

Martin

> 
> Cheers,
> Martin
> 
>>
>> regards,
>> Gaius
> 

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

> So please fix the crash I reported and I can convert GM2 texi manual.

will do,

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 8/31/22 15:19, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> How do you mean that? You should ideally generate .rst (Sphinx markup)
>> instead of the *.texi files. These will be then included in the converted
>> Sphinx manual similarly to how you include it now to the Texinfo manual.
>>
>> Does it make sense?
>>
>> Cheers,
>> Martin
> 
> ah right - yes this makes sense.

Goo!

> I mistakenly thought the .rst files
> could be automatically generated from texinfo sources.  In any case
> generating .rst directly will likely contain advantages,

Yes, that's what I'm doing for the existing documentation, but the conversion
is not perfect and I had to make some manual changes to the emitted .rst 
content.

So please fix the crash I reported and I can convert GM2 texi manual.

Cheers,
Martin

> 
> regards,
> Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

> How do you mean that? You should ideally generate .rst (Sphinx markup)
> instead of the *.texi files. These will be then included in the converted
> Sphinx manual similarly to how you include it now to the Texinfo manual.
>
> Does it make sense?
>
> Cheers,
> Martin

ah right - yes this makes sense.  I mistakenly thought the .rst files
could be automatically generated from texinfo sources.  In any case
generating .rst directly will likely contain advantages,

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 8/30/22 17:36, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>>>
>>> Another very brief update to say that I'm now tidying up the code and
>>> primary platform testing
>>>
>>> regards,
>>> Gaius
>>
>> Hello.
>>
>> As you may know I'm working on the documentation migration from texinfo to 
>> Sphinx
>> and I noticed you have quite some documentation written in Texinfo. Thus, I 
>> tried
>> using my conversion script, but ended with:
>>
>> $ m2/boot-bin/mc --olang=c++ --h-file-prefix=G
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libs
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libiberty
>> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-gcc --quiet
>> --gcc-config-system --extended-opaque
>> -o=m2/gm2-compiler-boot/M2GCCDeclare.c
>> /home/marxin/Programming/gcc2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
>> /*  --extended-opaque seen therefore no #include will be used and everything 
>> will be declared in full.  */
>> terminate called after throwing an instance of 'unsigned int'
>> Aborted (core dumped)
>>
>> $ Program received signal SIGSEGV, Segmentation fault.
>> 0x0043771e in decl_isConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
>> 22530  return n->kind == const_;
>> (gdb) bt
>> #0  0x0043771e in decl_isConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
>> #1  0x00432526 in addEnumConst (n=0xbabababababababa) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19914
>> #2  0x004313aa in visitNode (v=0x17cd5910, n=0xbabababababababa, 
>> p=...) at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19240
>> #3  0x00430ba9 in visitIntrinsic (v=0x17cd5910, n=0x5015c0, p=...) 
>> at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18871
>> #4  0x00430cc6 in visitDependants (v=0x17cd5910, n=0x5015c0, p=...) 
>> at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18923
>> #5  0x004313c1 in visitNode (v=0x17cd5910, n=0x5015c0, p=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19241
>> #6  0x004325b8 in populateTodo (p=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19938
>> #7  0x00432613 in topologicallyOut (c=..., t=..., v=..., tp=..., 
>> pc=..., pt=..., pv=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19957
>> #8  0x00426ffb in outDeclsImpC (p=0x17cc39a0, s=...) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:13910
>> #9  0x00432f2f in outImpC (p=0x17cc39a0, n=0x541800) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20142
>> #10 0x004337b5 in outC (p=0x17cc39a0, n=0x541800) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20285
>> #11 0x0043bd9b in decl_out () at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:26621
>> #12 0x0043eae6 in doCompile (s=0x50a190) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:223
>> #13 0x0043f646 in mcComp_compile (s=0x50a190) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:637
>> #14 0x00451d91 in init () at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:59
>> #15 0x00451da8 in _M2_top_init (argc=12, argv=0x7fffd9a8) at 
>> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:64
>> #16 0x0048b4c2 in main (argc=12, argv=0x7fffd9a8) at
>> m2/mc-boot/main.c:179
> 
> Hi Martin,
> 
> ah interesting - thanks for the trace will look into the above fault.

Hello.

Thanks.

> 
>> Have a couple of questions:
>>
>> 1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once
>> the branch is merged to master?
> 
> no it will be purged.  It was part of the tool set used to generate
> https://www.nongnu.org/gm2/homepage.html from gm2.texi.  createhtml
> allowed gcc-10, 11, 12 documentation to coexist.
> 
> I've seen and like the demos of the documentation you are producing.
> I was curious is there provision for older gcc release documentation
> (say gcc-10 onwards) to be accessible via the Sphinx’s documentation?

No, only for the current master branch.

> 
>> 2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
>> ./gcc/m2/Builtins.texi
>> Would it be possible emitting Sphinx in the future?
> 
> yes sure - I was meaning to email about this earlier.  Are there any
> do/don'ts you would advise when writing texinfo (or subset/template
> examples?).

How do you mean that? You should ideally generate .rst (Sphinx markup)
instead of the *.texi files. These will be then included in the converted
Sphinx manual similarly to how you include it now to the Texinfo manual.

Does it make sense?

Cheers,
Martin

> I'm keen to change the tools which generate gm2-ebnf.texi
> and Builtins.texi to accommodate Sphinx.
> 
> regards,
> Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Martin Liška  writes:

> On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
>> 
>> Another very brief update to say that I'm now tidying up the code and
>> primary platform testing
>> 
>> regards,
>> Gaius
>
> Hello.
>
> As you may know I'm working on the documentation migration from texinfo to 
> Sphinx
> and I noticed you have quite some documentation written in Texinfo. Thus, I 
> tried
> using my conversion script, but ended with:
>
> $ m2/boot-bin/mc --olang=c++ --h-file-prefix=G
> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libs
> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler
> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-libiberty
> -I/home/marxin/Programming/gcc2/gcc/m2/gm2-gcc --quiet
> --gcc-config-system --extended-opaque
> -o=m2/gm2-compiler-boot/M2GCCDeclare.c
> /home/marxin/Programming/gcc2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
> /*  --extended-opaque seen therefore no #include will be used and everything 
> will be declared in full.  */
> terminate called after throwing an instance of 'unsigned int'
> Aborted (core dumped)
>
> $ Program received signal SIGSEGV, Segmentation fault.
> 0x0043771e in decl_isConst (n=0xbabababababababa) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
> 22530   return n->kind == const_;
> (gdb) bt
> #0  0x0043771e in decl_isConst (n=0xbabababababababa) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
> #1  0x00432526 in addEnumConst (n=0xbabababababababa) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19914
> #2  0x004313aa in visitNode (v=0x17cd5910, n=0xbabababababababa, 
> p=...) at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19240
> #3  0x00430ba9 in visitIntrinsic (v=0x17cd5910, n=0x5015c0, p=...) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18871
> #4  0x00430cc6 in visitDependants (v=0x17cd5910, n=0x5015c0, p=...) 
> at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18923
> #5  0x004313c1 in visitNode (v=0x17cd5910, n=0x5015c0, p=...) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19241
> #6  0x004325b8 in populateTodo (p=...) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19938
> #7  0x00432613 in topologicallyOut (c=..., t=..., v=..., tp=..., 
> pc=..., pt=..., pv=...) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19957
> #8  0x00426ffb in outDeclsImpC (p=0x17cc39a0, s=...) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:13910
> #9  0x00432f2f in outImpC (p=0x17cc39a0, n=0x541800) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20142
> #10 0x004337b5 in outC (p=0x17cc39a0, n=0x541800) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20285
> #11 0x0043bd9b in decl_out () at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:26621
> #12 0x0043eae6 in doCompile (s=0x50a190) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:223
> #13 0x0043f646 in mcComp_compile (s=0x50a190) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:637
> #14 0x00451d91 in init () at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:59
> #15 0x00451da8 in _M2_top_init (argc=12, argv=0x7fffd9a8) at 
> /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:64
> #16 0x0048b4c2 in main (argc=12, argv=0x7fffd9a8) at
> m2/mc-boot/main.c:179

Hi Martin,

ah interesting - thanks for the trace will look into the above fault.

> Have a couple of questions:
>
> 1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once
> the branch is merged to master?

no it will be purged.  It was part of the tool set used to generate
https://www.nongnu.org/gm2/homepage.html from gm2.texi.  createhtml
allowed gcc-10, 11, 12 documentation to coexist.

I've seen and like the demos of the documentation you are producing.
I was curious is there provision for older gcc release documentation
(say gcc-10 onwards) to be accessible via the Sphinx’s documentation?

> 2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
> ./gcc/m2/Builtins.texi
> Would it be possible emitting Sphinx in the future?

yes sure - I was meaning to email about this earlier.  Are there any
do/don'ts you would advise when writing texinfo (or subset/template
examples?).  I'm keen to change the tools which generate gm2-ebnf.texi
and Builtins.texi to accommodate Sphinx.

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Martin Liška]

On 8/30/22 13:03, Gaius Mulley via Gcc-patches wrote:
> 
> Another very brief update to say that I'm now tidying up the code and
> primary platform testing
> 
> regards,
> Gaius

Hello.

As you may know I'm working on the documentation migration from texinfo to 
Sphinx
and I noticed you have quite some documentation written in Texinfo. Thus, I 
tried
using my conversion script, but ended with:

$ m2/boot-bin/mc --olang=c++ --h-file-prefix=G 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-libs 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-libiberty 
-I/home/marxin/Programming/gcc2/gcc/m2/gm2-gcc --quiet  --gcc-config-system 
--extended-opaque -o=m2/gm2-compiler-boot/M2GCCDeclare.c 
/home/marxin/Programming/gcc2/gcc/m2/gm2-compiler/M2GCCDeclare.mod
/*  --extended-opaque seen therefore no #include will be used and everything 
will be declared in full.  */
terminate called after throwing an instance of 'unsigned int'
Aborted (core dumped)

$ Program received signal SIGSEGV, Segmentation fault.
0x0043771e in decl_isConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
22530 return n->kind == const_;
(gdb) bt
#0  0x0043771e in decl_isConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:22530
#1  0x00432526 in addEnumConst (n=0xbabababababababa) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19914
#2  0x004313aa in visitNode (v=0x17cd5910, n=0xbabababababababa, p=...) 
at /home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19240
#3  0x00430ba9 in visitIntrinsic (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18871
#4  0x00430cc6 in visitDependants (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:18923
#5  0x004313c1 in visitNode (v=0x17cd5910, n=0x5015c0, p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19241
#6  0x004325b8 in populateTodo (p=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19938
#7  0x00432613 in topologicallyOut (c=..., t=..., v=..., tp=..., 
pc=..., pt=..., pv=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:19957
#8  0x00426ffb in outDeclsImpC (p=0x17cc39a0, s=...) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:13910
#9  0x00432f2f in outImpC (p=0x17cc39a0, n=0x541800) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20142
#10 0x004337b5 in outC (p=0x17cc39a0, n=0x541800) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:20285
#11 0x0043bd9b in decl_out () at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gdecl.c:26621
#12 0x0043eae6 in doCompile (s=0x50a190) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:223
#13 0x0043f646 in mcComp_compile (s=0x50a190) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/GmcComp.c:637
#14 0x00451d91 in init () at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:59
#15 0x00451da8 in _M2_top_init (argc=12, argv=0x7fffd9a8) at 
/home/marxin/Programming/gcc2/gcc/m2/mc-boot/Gtop.c:64
#16 0x0048b4c2 in main (argc=12, argv=0x7fffd9a8) at 
m2/mc-boot/main.c:179

Have a couple of questions:

1) What's gcc/m2/www/tools/createhtml.py about? Will you need it once the 
branch is merged to master?
2) You generate some texi files on fly: ./gcc/m2/gm2-ebnf.texi, 
./gcc/m2/Builtins.texi
Would it be possible emitting Sphinx in the future?

Thanks,
Martin

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Another very brief update to say that I'm now tidying up the code and
primary platform testing

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> Rainer Orth  writes:
>
>>> I think this just leaves:
>>>
 * While this lets the build finish on all of i386-pc-solaris2.11,
   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
   testsuite failures, all of the same kind:

 Undefined   first referenced
  symbol in file
 RTco_signal 
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_select 
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_initSemaphore  
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 RTco_wait   
 /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
 ld: fatal: symbol referencing errors
 collect2: error: ld returned 1 exit status
 compiler exited with status 1
 FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g

   I haven't yet tried to fix those.
>>>
>>> which I'll try and reproduce,
>>
>> Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
>> Solaris-specific issue.
>
> Hi Rainer,
>
> I think these are now fixed

indeed, thanks.

However, there are still a couple of issues with the branch:

* There's an unresolved merge conflict in toplevel Makefile.in.

* Bootstrap on i386-pc-solaris2.11 initially fails with

/vol/gcc/src/hg/master/modula-2/gcc/gcc.cc: In function 'void 
print_option(const char*, unsigned int, cl_decoded_option*)':
/vol/gcc/src/hg/master/modula-2/gcc/gcc.cc:4805:46: error: format '%ld' expects 
argument of type 'long int', but argument 2 has type 'std::size_t' {aka 
'unsigned int'} [-Werror=format=]
 4805 |   printf (" canonical_option_num_elements [%ld]\n",
  |~~^
  |  |
  |  long int
  |%d
 4806 |   in_decoded_options[i].canonical_option_num_elements);
  |   ~~~
  | |
  | std::size_t {aka unsigned int}

  Fixed by the attached patch.

* The libgm2 build fails with

make[5]: *** No rule to make target 'KeyBoardLEDs.c', needed by 
'KeyBoardLEDs.lo'.  Stop.

  While libgm2/libm2cor/Makefile.am had been updated for the rename, the
  corresponding Makefile.in hasn't.  Besides, the Makefile.in's are
  still generated with a distribution-patched automake (which supports
  runstatedir).  This makes it unnecessarily hard to check if
  everything's ok if you have to update Makefile.am's and run automake
  locally afterwards.

That said, results are pretty good:

* i386-pc-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11650
# of unexpected failures14

=== gm2 Summary for unix/-m64 ===

# of expected passes11647
# of unexpected failures17

=== gm2 Summary ===

# of expected passes23297
# of unexpected failures31

* amd64-pc-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11658
# of unexpected failures6

=== gm2 Summary for unix/-m32 ===

# of expected passes11650
# of unexpected failures14

=== gm2 Summary ===

# of expected passes23308
# of unexpected failures20

* sparcv9-sun-solaris2.11:

=== gm2 Summary for unix ===

# of expected passes11653
# of unexpected failures9
# of unresolved testcases   1

=== gm2 Summary for unix/-m32 ===

# of expected passes7390
# of unexpected failures2131
# of unresolved testcases   2029

=== gm2 Summary ===

# of expected passes19043
# of unexpected failures2140
# of unresolved testcases   2030

  The 32-bit failures are mostly (all?) of the same type.  I've filed PR
  modula2/106443 for that

* sparc-sun-solaris2.11:

  Still fails with a cc1gm2 SEGV in stage2: PR modula2/101392.

And just for completeness' sake:

* x86_64-pc-linux-gnu:

=== gm2 Summary for unix ===

# of expected passes11662
# of unexpected failures2

=== gm2 Summary for unix/-m32 ===

# of expected passes11657
# of unexpected failures7

=== gm2 Summary ===

# of expected passes23319
# of unexpected failures9

* i686-pc-linux-gnu:

=== gm2 Summary for unix ===

# of expected passes11663
# of unexpected failures1

=== gm2 Summary 

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

>> I think this just leaves:
>>
>>> * While this lets the build finish on all of i386-pc-solaris2.11,
>>>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>>>   testsuite failures, all of the same kind:
>>>
>>> Undefined   first referenced
>>>  symbol in file
>>> RTco_signal 
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_select 
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_initSemaphore  
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> RTco_wait   
>>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>>> ld: fatal: symbol referencing errors
>>> collect2: error: ld returned 1 exit status
>>> compiler exited with status 1
>>> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>>>
>>>   I haven't yet tried to fix those.
>>
>> which I'll try and reproduce,
>
> Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
> Solaris-specific issue.

Hi Rainer,

I think these are now fixed

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> many thanks for the patch and log of the failures.  I've committed the
> patch and rebuilt all Makefile.in's which are affected by m2.

thanks.  I've noticed that libgm2/configure has been generated with a
patched autoconf which includes runstatedir, unlike the upstream
version.  It's just a nit, but confusing.

> I think this just leaves:
>
>> * While this lets the build finish on all of i386-pc-solaris2.11,
>>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>>   testsuite failures, all of the same kind:
>>
>> Undefined   first referenced
>>  symbol in file
>> RTco_signal 
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_select 
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_initSemaphore  
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> RTco_wait   
>> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
>> ld: fatal: symbol referencing errors
>> collect2: error: ld returned 1 exit status
>> compiler exited with status 1
>> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>>
>>   I haven't yet tried to fix those.
>
> which I'll try and reproduce,

Excellent.  I've also seen this one on Linux/x86_64, so this isn't a
Solaris-specific issue.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

Hi Rainer,

many thanks for the patch and log of the failures.  I've committed the
patch and rebuilt all Makefile.in's which are affected by m2.

I think this just leaves:

> * While this lets the build finish on all of i386-pc-solaris2.11,
>   sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
>   testsuite failures, all of the same kind:
>
> Undefined   first referenced
>  symbol in file
> RTco_signal 
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_select 
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_initSemaphore  
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> RTco_wait   
> /var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
> ld: fatal: symbol referencing errors
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g
>
>   I haven't yet tried to fix those.

which I'll try and reproduce,

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> thanks for the report - the first bug report (above) is now fixed on
> devel/modula-2.

thanks, that got me closer, but not quite there yet:

* First, I get:

/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs-min/SYSTEM.mod:29:1: error: In 
implementation module 'SYSTEM': module 'M2RTS' does not export procedure 
'RequestDependant'
/vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod:29:1:
 error: In implementation module 'M2RTS': module 'M2RTS' does not export 
procedure 'RegisterModule'
/vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/SYSTEM.mod:29:1:
 error: In implementation module 'SYSTEM': module 'M2RTS' does not export 
procedure 'RequestDependant'

  Fixed by adding dummy declarations/definitions as in the attached patch.

* Then, I run into

make[9]: Entering directory 
'/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/amd64/libgm2/libm2pim'
Makefile:913: warning: ignoring prerequisites on suffix rule definition
make[9]: *** No rule to make target 'UnixArgs.c', needed by 
'libm2pim_la-UnixArgs.lo'.
make[9]: *** No rule to make target 'Selective.c', needed by 
'libm2pim_la-Selective.lo'.
make[9]: *** No rule to make target 'sckt.c', needed by 'libm2pim_la-sckt.lo'.
make[9]: *** No rule to make target 'errno.c', needed by 'libm2pim_la-errno.lo'.
make[9]: *** No rule to make target 'dtoa.c', needed by 'libm2pim_la-dtoa.lo'.
make[9]: *** No rule to make target 'ldtoa.c', needed by 'libm2pim_la-ldtoa.lo'.
make[9]: *** No rule to make target 'termios.c', needed by 
'libm2pim_la-termios.lo'.
make[9]: *** No rule to make target 'SysExceptions.c', needed by 
'libm2pim_la-SysExceptions.lo'.
make[9]: Target 'all-am' not remade because of errors.
make[9]: Leaving directory 
'/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/amd64/libgm2/libm2pim'

  It turns out none of the generated auto* files had been regenerated in
  tree; fixed by running autoconf; autoheader; automake.

* Next, on Solaris only:

/vol/gcc/src/hg/master/modula-2/libgm2/libm2pim/dtoa.cc: In function 'int 
dtoa_calcmaxsig(char*, int)':
/vol/gcc/src/hg/master/modula-2/libgm2/libm2pim/dtoa.cc:139:7: error: 'index' 
was not declared in this scope; did you mean 'index_t'?
  139 |   e = index (p, 'E');
  |   ^
  |   index_t
/vol/gcc/src/hg/master/modula-2/libgm2/libm2pim/dtoa.cc: In function 'int 
dtoa_calcdecimal(char*, int, int)':
/vol/gcc/src/hg/master/modula-2/libgm2/libm2pim/dtoa.cc:171:7: error: 'index' 
was not declared in this scope; did you mean 'index_t'?
  171 |   e = index (p, 'E');
  |   ^
  |   index_t

  While index is declared in , the declaration is guarded by
  !_XPG7 || __EXTENSIONS__, but g++ defines _XPG7/_XOPEN_SOURCE=700 on
  Solaris.  I think it's better to just use the standard strchr instead,
  as the attached patch does.

* While this lets the build finish on all of i386-pc-solaris2.11,
  sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu, I get thousands of
  testsuite failures, all of the same kind:

Undefined   first referenced
 symbol in file
RTco_signal 
/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
RTco_select 
/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
RTco_initSemaphore  
/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
RTco_wait   
/var/gcc/modula-2/11.4-gcc-modula-2/i386-pc-solaris2.11/./libgm2/libm2pim/.libs/libm2pim.so
ld: fatal: symbol referencing errors
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: gm2/exceptions/run/pass/libexcept.mod compilation,  -g

  I haven't yet tried to fix those.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University


diff --git a/gcc/m2/gm2-libs-min/M2RTS.def b/gcc/m2/gm2-libs-min/M2RTS.def
--- a/gcc/m2/gm2-libs-min/M2RTS.def
+++ b/gcc/m2/gm2-libs-min/M2RTS.def
@@ -31,11 +31,17 @@ DEFINITION MODULE M2RTS ;
 
 FROM SYSTEM IMPORT ADDRESS ;
 
+TYPE
+   ArgCVEnvP = PROCEDURE (INTEGER, ADDRESS, ADDRESS) ;
 
 (*
all these procedures do nothing except satisfy the linker.
 *)
 
+PROCEDURE RegisterModule (name: ADDRESS;
+  init, fini:  ArgCVEnvP;
+  dependencies: PROC) ;
+PROCEDURE RequestDependant (modulename, dependantmodule: ADDRESS) ;
 PROCEDURE ExecuteTerminationProcedures ;
 PROCEDURE ExecuteInitialProcedures ;
 PROCEDURE HALT ;
diff --git a/gcc/m2/gm2-libs-min/M2RTS.mod b/gcc/m2/gm2-libs-min/M2RTS.mod
--- a/gcc/m2/gm2-libs-min/M2RTS.mod
+++ b/gcc/m2/gm2-libs-min/M2RTS.mod
@@ -70,4 +70,10 @@ BEGIN
 END DeconstructModules ;
 
 
+PROCEDURE RegisterModule (name: ADDRESS;
+  init, fini:  

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Rainer Orth  writes:

> Hi Gaius,
>
>> A very brief update to say that I've merged the new linking
>> implementation back onto the devel/modula-2 branch,
>
> unfortunately, that branch doesn't bootstrap for me anywere:
>
> * On both x86_64-pc-linux-gnu and i386-pc-solaris2.11:
>
> libtool: compile:  /var/gcc/modula-2/11.4-gcc-modula-2/./gcc/gm2 
> -B/var/gcc/modula-2/11.4-gcc-modula-2/./gcc/ -c -g -O2 -g -O2 -I. 
> -I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs-min 
> -I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs -fno-exceptions 
> -fno-m2-plugin 
> /vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod
>   -fPIC -DPIC -o .libs/M2RTS.o
> /vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod:29:1:
>  error: In implementation module ‘M2RTS’: module does not export procedure 
> which is a necessary component of the runtime system, hint check the path and 
> library/language variant
>29 | IMPORT libc, SYSTEM ;
>   | ^~
> make[5]: *** [Makefile:746: M2RTS.lo] Error 1

Hi Rainer,

thanks for the report - the first bug report (above) is now fixed on
devel/modula-2.

Thanks for the gdb output for PR modula2/101392 (still outstanding)

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

>> A very brief update to say that I've merged the new linking
>> implementation back onto the devel/modula-2 branch,
>
> unfortunately, that branch doesn't bootstrap for me anywere:
[...]
> * On sparc-sun-solaris2.11:
[...]
>   Seems like PR modula2/101392 raised its ugly head again, after it had
>   been gone for a while.  I'm currently trying sparcv9-sun-solaris2.11
>   instead to see how that fares.

as expacted the Solaris/sparcv9 bootstrap got into building the target
libs, then failing in the same way as on Solaris/x86 and Linux/x86_64.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Rainer Orth]

Hi Gaius,

> A very brief update to say that I've merged the new linking
> implementation back onto the devel/modula-2 branch,

unfortunately, that branch doesn't bootstrap for me anywere:

* On both x86_64-pc-linux-gnu and i386-pc-solaris2.11:

libtool: compile:  /var/gcc/modula-2/11.4-gcc-modula-2/./gcc/gm2 
-B/var/gcc/modula-2/11.4-gcc-modula-2/./gcc/ -c -g -O2 -g -O2 -I. 
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs-min 
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs -fno-exceptions 
-fno-m2-plugin 
/vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod
  -fPIC -DPIC -o .libs/M2RTS.o
/vol/gcc/src/hg/master/modula-2/libgm2/libm2min/../../gcc/m2/gm2-libs-min/M2RTS.mod:29:1:
 error: In implementation module ‘M2RTS’: module does not export procedure 
which is a necessary component of the runtime system, hint check the path and 
library/language variant
   29 | IMPORT libc, SYSTEM ;
  | ^~
make[5]: *** [Makefile:746: M2RTS.lo] Error 1

  and several more.

* On sparc-sun-solaris2.11:

/bin/ksh /vol/gcc/src/hg/master/modula-2/gcc/m2/tools-src/makeSystem -fpim \
 /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/SYSTEM.def \
 /vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/SYSTEM.mod \
 -I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs \
 "/var/gcc/modula-2/11.4-gcc-modula-2/./gcc/gm2 
-B/var/gcc/modula-2/11.4-gcc-modula-2/./gcc/ -fno-checking" 
/var/gcc/modula-2/11.4-gcc-modula-2/gcc/m2/gm2-libs/SYSTEM.def
gm2: internal compiler error: Segmentation Fault signal terminated program 
cc1gm2
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See  for instructions.
SYSTEM module creates type: LOC
SYSTEM module creates type: WORD
SYSTEM module creates type: BYTE
SYSTEM module creates type: ADDRESS
SYSTEM module creates type: INTEGER8
SYSTEM module creates type: INTEGER16
SYSTEM module creates type: INTEGER32
SYSTEM module creates type: INTEGER64
SYSTEM module creates type: CARDINAL8
SYSTEM module creates type: CARDINAL16
SYSTEM module creates type: CARDINAL32
SYSTEM module creates type: CARDINAL64
SYSTEM module creates type: WORD16
SYSTEM module creates type: WORD32
SYSTEM module creates type: WORD64
SYSTEM module creates type: BITSET8
SYSTEM module creates type: BITSET16
SYSTEM module creates type: BITSET32
SYSTEM module creates type: REAL32
SYSTEM module creates type: REAL64
SYSTEM module creates type: REAL128
SYSTEM module creates type: COMPLEX32
SYSTEM module creates type: COMPLEX64
SYSTEM module creates type: COMPLEX128
SYSTEM module creates type: CSIZE_T
SYSTEM module creates type: CSSIZE_T
gm2: internal compiler error: Segmentation Fault signal terminated program 
cc1gm2
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
See  for instructions.
make[3]: *** [/vol/gcc/src/hg/master/modula-2/gcc/m2/Make-lang.in:1237: 
/var/gcc/modula-2/11.4-gcc-modula-2/gcc/m2/gm2-libs/SYSTEM.def] Error 4
make[3]: Leaving directory '/var/gcc/modula-2/11.4-gcc-modula-2/gcc'
make[2]: *** [Makefile:5055: all-stage2-gcc] Error 2

cc1gm2 -quiet -mcpu=v9 -fpim -fno-scaffold-main -fno-scaffold-dynamic 
-fno-scaffold-static -fno-m2-plugin -fdump-system-exports -c 
-I/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs 
-I/usr/local/lib/gcc/sparc-sun-solaris2.11/13.0.0/m2/m2pim 
/vol/gcc/src/hg/master/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0xffbfe364 in ?? ()
(gdb) bt
#0  0xffbfe364 in ?? ()
#1  0x0064be24 in m2expr_BuildBinarySetDo ()
#2  0x006a5634 in CodeBinarySetShift(m2expr_BuildSetProcedure_p, DoProcedure_p, 
unsigned int, unsigned int, unsigned int, unsigned int, unsigned int, unsigned 
int, unsigned int) ()
#3  0x006ae0e8 in M2GenGCC_ConvertQuadsToTree ()
#4  0x006ccc14 in M2Scope_ForeachScopeBlockDo ()
#5  0x006a2014 in M2Code_CodeBlock ()
#6  0x006ca324 in Lists_ForeachItemInListDo ()
#7  0x006936a0 in SymbolTable_ForeachProcedureDo ()
#8  0x006a2194 in M2Code_CodeBlock ()
#9  0x006a2608 in M2Code_Code ()
#10 0x00684214 in M2Comp_compile ()
#11 0x00627b5c in gm2_langhook_parse_file() ()
#12 0x00d8c968 in compile_file() ()
#13 0x00d905fc in toplev::main(int, char**) ()
#14 0x01a092dc in main ()

  Seems like PR modula2/101392 raised its ugly head again, after it had
  been gone for a while.  I'm currently trying sparcv9-sun-solaris2.11
  instead to see how that fares.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

A very brief update to say that I've merged the new linking
implementation back onto the devel/modula-2 branch,

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Hi,

all 11k regression tests pass with the new linking implementation (on
devel/m2link).  I plan to migrate the patches back to devel/modula-2 and
then remove devel/m2link.  Thereafter {polish,test} and generate new
patch sets.  Thanks for the clear explanation on how the dynamic
scaffold should work!

regards,
Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Richard Biener via Gcc-patches]

> Am 17.06.2022 um 19:09 schrieb Gaius Mulley via Gcc-patches 
> :
> 
> 
> New linking implementation is complete, gcc bootstraps and hello
> world links.  I'll git push the changes, then test/debug/polish and
> produce new patch sets

Great!

Thanks,
Richard 

> regards,
> Gaius

Re: Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

New linking implementation is complete, gcc bootstraps and hello
world links.  I'll git push the changes, then test/debug/polish and
produce new patch sets

regards,
Gaius

Modula-2: merge followup (brief update on the progress of the new linking implementation)

[Gaius Mulley via Gcc-patches]

Here is a brief synopsis of the new linking implementation.

Completed: runtime module dependency resolution, IR scaffold and IR
runtime dependency graph and the compiler driver.

Todo: per module ctors.

The proposed road map: once helloworld links using the new scheme I
plan to git push the updates.  Thereafter debug, test, polish and then
generate new patch sets.  Feel free to make suggestions though,

regards,
Gaius