Dear Frank
The reason I use this odd style is because the program involved is part of a suite of numerical programs which were originally written using Suns Pascal compiler. It was then ported to Decs Pascal, then finally to gpc. The original code used this style of modules and global variables (actually there are only 2 if I remember correctly) and both Sun and Dec pascal support this style. gpc almost does :) or did. I can't change the program code because lots of user models have been written against this and they would stop compiling if I changed something like this.
Can anyone suggest a workaround ? Thanks again
Ian
On Friday 18 May 2001 17:06, you wrote:
Ian Thurlbeck wrote:
After 2 years of using gpc I thought I'd better update to a newer release, so I have installed gcc-2.95.3 and gpc-20010512.
It appears than an old bug has resurfaced. A global variable declared in a module is not initialised properly.
The following code does NOT print out the string 'OK':
-------main.h------------ var s: string(40); external;
procedure print_globals; external;
-------main.p------------ program main(input,output);
#include "main.h"
begin s:='OK'; print_globals; end.
-------lib.p------------- module lib(input,output);
#include "main.h"
var s:string(40);
procedure print_globals; begin writeln(s); end;
end.
Compile with 'gpc -o main main.p lib.p'
If you move the declaration of string 's' from lib.p to main.p it works.
This was fixed about 2 years ago (by Peter I think) but it seems to have gotten un-fixed.
Yes, it was "un-fixed" indeed, to fix other, more important (IMHO) bugs.
The problem is that you use the module in a quite strange (C-ish) way rather than the normal EP `imports' or perhaps the BP `uses'.
GPC generates initialization code for the module which sets the string. But how should the main program know that it should call this initializer? All it sees is an external declaration of a variable -- and normally, it must not initialize external variables because they "belong" to another module (or similar).
The way it was done before is to have the initializers called via some linker hack. This had a number of problems: It didn't work at all on some systems (e.g. IRIX, and anything that does not use GNU ld, IIRC), and even where it did, the order of initializers run was "undefined" or at least not always right which caused problems if the initializer code of one module relied on that of another one already having been run. There may have been more problems ...
So we changed this so the initializers are now called normally from the program and/or the using/importing module/unit's initializers. This works well -- as long as the program/module/unit knows which initializers to call, i.e. not in your case.
I'm not sure why you do it like this -- perhaps it's just a relic from ancient times when GPC didn't know about importing interfaces. In this case, I'd suggest to get rid of it.
Otherwise, any ideas for fixing this are welcome.
Frank