I see you have solved the mysterious failures. FWIW, yesterday
I created a clean directory and tried "test_run" again, as below,
except this time I redirected the output of the first run, as well as
the second run. In fact (as you no doubt have also discovered),
the first run (of "test_run") produces no failures, only the second
run does.
I also downloaded 'upx' V1.20 and am very impressed with it!
It was able to achieve even better compression of the 210K
executable file than either 'gzip' or 'zip', by about 5%. The
approximate results are as follows (both compiled with GPC) :
hello.c :
initial size = 13K
after 'strip' = 3K
after 'upx' = too small to compress (3K)
hello.p :
initial size = 550K
after 'strip' = 210K
after 'upx' = 62K
So, the smallest GPC executable, using 'strip' and 'upx', is
about 62K, which is tolerable. I haven't yet checked what
effect the compiler flags have on this, so there might be
some more savings possible.
Since 'upx' is also available for DOS, I will probably try it
on the DJGPP version of GPC as well ... :-)
Joe.
-----Original Message-----
From: Frank Heckenbach [SMTP:frank@g-n-u.de]
Sent: Wednesday, April 24, 2002 11:09 PM
To: gpc@gnu.de
Subject: Re: GPC 2.1 RC 6 released
da Silva, Joe wrote:
As expected, the "bill.pas" and "confarr9.pas" tests were OK
with the "--automake" option. Although, thinking about it again
now, I'm not sure why the required units for these programs
weren't supplying the "missing" identifiers, since the failures
reported below occurred on the second run of the script file,
so the relevant units would/should have been available in
compiled form.
I don't really understand either, and can't seem to reproduce it. If
you can give me a recipe how to provoke the problem, starting from a
clean test directory, I might be able to say more ...
[Joe da Silva]
As far as I recall, I simply :
- Changed to the (pristine) test directory
- Typed "./test_run"
- Typed "./test_run > results.gpc"
- Extracted the failure details from "results.gpc"
Ah, now I see. The problem is that several test programs (in
particular, bill.pas and kevin5.pas) used an interface called `Foo',
so foo.gpi compiled from kevin5.pas was included when bill.pas
searched for its interface `Foo' in the 2nd turn. Same with `Test1'
(confarr9.pas and rphil6.pas). I'm renaming these now, to be sure.
Should I add some "magic" variables to protect test_run from being
run except via make?
[Joe da Silva]
Maybe. Or maybe just include a comment at the
top of "test_run" such as :
"Important : Read the README file first!"
Since probably not everyone looks into a script before starting it,
I'm doing both ...
Hmmm ... so the 13K executable isn't self-contained?
Not at all. Run `ldd filename' to see the dynamic library
dependencies, or compile with `-static' to get a self-contained
statically linked binary.
Does that mean that if this executable were redistributed,
it might not run, depending on the version of RTS available
on the recipient machine (assuming the same architecture
of course)?
In Pascal, quite likely, unless you distribute the RTS with it. In
C, the problem is less severe, since the interface of libc (C's
"RTS") is more stable. But still, there are enough subtle
differences, especially between different Linux distributions, so I
prefer to distribute any Linux binaries statically linked. YMMV.
Frank
--
Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html