Angelo FUMAGALLI wrote:
Hello,
we are using gpc-20041218 with gcc-2.95.2 on Sparc Solaris 2.8 and we found a gpc link problem when linking user object file compiled separately and then linked in a final step.
For example, a simple case: if we have two gpc source files (a program pi.pas which calls a procedure defined in a separeted unit ui.pas which uses the gpc Trap unit) compiled in different steps and then linked together in a final step, the references related to the gpc unit remain undefined when linking/loading the object files, for example:
gpc --automake -c ui.pas -o ui.o gpc --automake -c pi.pas -o pi.o gpc --automake pi.o ui.o -o p.exe
Undefined first referenced symbol in file Trappedexitcode ui.o _p_TrapExec ui.o Trappederrormessagestring ui.o init_Trap ui.o _p_TrapReset ui.o ld: fatal: Symbol referencing errors. No output written to p.exe collect2: ld returned 1 exit status
by other hands compiling first the module ui.pas, then the program p1.pas and linking the ui.o in the same gpc commad there are no undefined references at linkink/loading step, example:
gpc --automake -c ui.pas -o ui.o gpc --automake pi.pas ui.o -o p.exe
Some suggestion to solve the above problem?
The official way is:
gpc --automake pi.pas -o p.exe
Automake will then recompile what is needed and link everything. If you type:
gpc --automake pi.o ui.o -o p.exe
you have effectively disabled automake -- the ".o" files contain too little info compared to Pascal source. If you really want to link ".o" files you should give _complete_ list of ".o" files:
gpc pi.o ui.o trap.o -o p.exe
Note that given Pascal source automake can automatically determine that "trap.o" is needed.