gm2
[Top][All Lists]
Advanced

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

Re: Compiling main module | linking


From: Gaius Mulley
Subject: Re: Compiling main module | linking
Date: Fri, 12 May 2023 20:27:38 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi Michael,

Michael Riedl <udo-michael.riedl@t-online.de> writes:

> Gaius,
>
> perhaps I am doing something wrong but I do not get my main programs
> finally compiled and linked:
>
> Here, as a sample, the options for the final compilation of the main
> module. It takes unrealistic long time for the compilation (M2RHF.mod
> is bit longer than 500 lines of code) and then "strange" error
> messages are printed to the terminal and the compiler terminated:
>
> user@hostname:~/.../Chemie/scf/quellen.gm2$time make
> gm2 -c -fiso -flibs=m2iso,m2pim,m2log -I
> /usr/local/home/user/Modula-2/Numerik/quellen.gm2 -I 
> /usr/local/home/user/Modula-2/InOut/quellen.gm2 -I
> /home/user/Modula-2/Numerik/TestRoutinen/LinAlg -I 
> /home/user/Modula-2/StringHandler  -O1 -fscaffold-main  M2RHF.mod
> /usr/local/home/user/Modula-2/Numerik/quellen.gm2/LMathLib.mod:478:36:
> error: In procedure »sinh«: the constructor type is »ChebVek« and this 
> is different from the constant constant set which has a type »BITSET«
>   478 |           CONST ChebKoeff = ChebVek{ (* Slatex DSINH *)
>       |                                    ^
> /usr/local/home/user/Modula-2/Numerik/quellen.gm2/LMathLib.mod:518:36:
> error: In procedure »cosh«: the constructor type is »ChebVek« and this 
> is different from the constant constructor which has a type »ChebVek«
>   518 |           CONST ChebKoeff = ChebVek{ (* coshm1 *)
>       |                                    ^
> ./PeriSys.mod:198:35: error: In procedure »NEdelGas«: the constructor
> type is »PrSy« and this is different from the constant constant set 
> which has a type »GenOptSet«
>   198 |           CONST EdelGasKern = PrSy{ 0 BY  2,  (* H  - He : (--) *)
>       |                                   ^
> ./PeriSys.mod:198:44: error: cannot mix construction of a array with a set
>   198 |           CONST EdelGasKern = PrSy{ 0 BY  2,  (* H  - He : (--) *)
>       |                                            ^
> Makefile:37: recipe for target 'M2RHF.o' failed
> make: *** [M2RHF.o] Error 1
>
> real    6m23,878s
> user    6m13,243s
> sys    0m0,958s
> user@hostname:~/.../Chemie/scf/quellen.gm2$
>
> --------
>
> E.g. the module PeriSys.mod does compile without any issue
>
> user@hostname:~/.../Chemie/scf/quellen.gm2$make PeriSys.o
> gm2 -c -fiso -flibs=m2iso,m2pim,m2log -I
> /usr/local/home/user/Modula-2/Numerik/quellen.gm2 -I 
> /usr/local/home/user/Modula-2/InOut/quellen.gm2 -I
> /home/user/Modula-2/Numerik/TestRoutinen/LinAlg -I 
> /home/user/Modula-2/StringHandler  -O1 PeriSys.mod
> user@hostname:~/.../Chemie/scf/quellen.gm2$ls PeriSys.o
> PeriSys.o
>
> user@hostname:~/.../Chemie/scf/quellen.gm2$
>
> as does the module LMathLib.mod. Seems that the compiler re-compiles
> all modules involved in the project and has some internal buffer
> overflow or the like (all modules involved have approx 80.000 lines of
> code (not counting the Fortran parts) - bit "too much" to do all at
> the same time). And this although I did NOT use "-fm2-whole-program"
> :-)

ah the default linking options will attempt to generate a complete list
of all modules used for your project and will follow all def/mod files.
If you are confident that the list of modules remains the same between
links you could shortcut the time by generating the list of module using
-fgen-module-list=foo.lst and then perform a faster link using
-fuse-list=foo.list for example on one of my projects:

$ gm2 -fsources -O0 -fsoft-check-all -fm2-g -g -fextended-opaque \
  -fgen-module-list=foo.list -I. -I../../penguin-tower/src \
  ../../penguin-tower/src/Dungeon.mod AdvCmd.o AdvIntroduction.o \
  AdvMap.o \
  AdvMath.o AdvSound.o AdvSystem.o AdvTreasure.o AdvUtil.o AdvParse.o \
  DrawG.o DrawL.o Lock.o ProcArgs.o Screen.o Window.o SocketControl.o \
  advflex.o -o ptower

$ gm2 -fsources -O0 -fsoft-check-all -fm2-g -g -fextended-opaque \
  -fuse-list=foo.list -I. -I../../penguin-tower/src \
  ../../penguin-tower/src/Dungeon.mod AdvCmd.o AdvIntroduction.o AdvMap.o \
  AdvMath.o AdvSound.o AdvSystem.o AdvTreasure.o AdvUtil.o AdvParse.o \
  DrawG.o DrawL.o Lock.o ProcArgs.o Screen.o Window.o SocketControl.o \
  advflex.o -o ptower

> Not splitting the compilation and linking of the main module makes no
> difference - same "error" messages and no executable.
>
> Linking the smaller programs in the same way does not show this effect
> - but they are all in the range of 2000 - 10.000 lines of code and of 
> lower complexity.

however re: the crash issue - not really much idea - is there any chance
I could have a tarball of your source code just to run cc1gm2 under gdb?
Or maybe is it easier (given the size of the project) for you to run gdb
on cc1gm2?

If so you could firstly run gm2 for the offending link with -v

$ gm2 -v etc

(cut n paste the very long cc1gm2 line)

$ cd gcc-build-dir/gcc
$ make m2/stage2/cc1gm2 && cp m2/stage2/cc1gm2 .
edit gcc-src-dir/gcc/gdbinit.in and paste the cut line at the bottom
with:

     break exit
     run "pasted buffer"

save and quit gdbinit.in

then at the command line:

$ gdb cc1gm2
(gdb) where
(gdb) quit

and email me the gdb output :-)

Ah maybe even easier just run the cc1gm2 line under valgrind?

$ valgrind cc1gm2 pasted long line

regrads,
Gaius

reply via email to

[Prev in Thread] Current Thread [Next in Thread]