[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