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
da Silva, Joe wrote:
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) :
FWIW, bzip2 compresses most file substantially better than gzip/zip. I don't know if upx uses the bzip2 algorithms, but I suppose not, so there might be room for more improvement if it uses it ...
Frank