Please see below ...
Joe.
-----Original Message----- From: Frank Heckenbach [SMTP:frank@g-n-u.de] Sent: Wednesday, April 24, 2002 12:41 PM To: gpc@gnu.de Subject: Re: GPC 2.1 RC 6 released
da Silva, Joe wrote:
Well, I did some more experimenting last night ...
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 :
1. Changed to the (pristine) test directory 2. Typed "./test_run" 3. Typed "./test_run > results.gpc" 4. Extracted the failure details from "results.gpc"
Not surprisingly, the "--automake" option didn't make any difference to the "fjf623.pas" test program.
At this point, I had another look at all the files in the test directory and discovered one called "README" <G>. As you may have guessed by now, I was just running the "test_run" script file (executable files are highlighted in bright green on my directory listings, so the script files were what I had noticed, and the "test_run" script file in particular, looked like the right thing to run).
Oh well ...
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!"
So, running the mysterious "make" command instead (which seemed to supply a number of option flags to GPC, including "--automake"), no errors were reported (there were 8 tests skipped, because of some stuff I haven't installed)! I don't yet know which option flag fixed the "fjf623.pas" failure, although I suspect it might be the "-Wall" flag. I may investigate further, for curiosity.
It was probably the `rm'. ;-) The error that fjf623 is meant to provoke occurs when the units are compiled. If they have been compiled in a previous run already, the error doesn't show.
I will check the FAQ again about the executable file size. I recall previous discussions about using "strip", but this only shrunk the file to over 200K. I don't have "upx" (yet), so I then simply zipped the 200K file, to see how compressible it was. I can't recall the exact result, but it was still much, much larger than the 13K executable produced by GPC, when it compiled the C version of the "hello" program.
I didn't mean the FAQ document (apparently, it's only updated sparingly -- when someone likes to add something, just send me the text, preferable as a diff to faq.text; I don't really have the time to maintain this document), but this list.
In short: The RTS is linked statically. It is possible to build and link it dynamically (make WITH_SHARED=yes), but since its interface changes often, you might end up with a lot of RTS .so's over time that some of your binaries depend on.
[Joe da Silva]
Hmmm ... so the 13K executable isn't self-contained? 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)?
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:
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