frank at g-n-u.de
Wed Mar 5 02:06:06 CET 2003
Grant Jacobs wrote:
> >If really no object files are generated, this would be a rather
> >serious bug.
> No .o files for those units in other directories, even though their
> .gpi files are present. And the are not built into the other
> directories either. For the units in the current directory, all the
> .o files are made.
> >Can you send me the output of a full (i.e., `--autobuild', or after
> >removing all .gpi files) compilation with `-v' (verbose), with a
> >preferably simple example that exhibits this bug?
> I'll try get onto this, but basically its just a list of linker
> errors; all of which are unresolved references to the routines the
> units in the current directory need from the units found in the other
> directories. Since their .o files are not present, that's not
> surprising! I'm not really sure what you'd learn from that.
Linking is the last step. I'm interested in the messages from the
compiler runs before that (which are output with `-v'). If you like,
you can omit the linker messages -- the .o files should have been
created by the time the linker is invoked, and if not, the error
must be before that.
> This is particularly annoying on the odd occasion when I change a
> unit only to find that the compiler now complains about wanting to
> 'recompile unit XXX in the proper order' despite the fact I've only
> changed one unit.
A message to compile *one* unit in the proper order would be
confusing indeed. ;-) But I'm only aware of a message to "recompile
interfaces in the right order". This is output when automake is
either disabled or doesn't have enough information (see below) to
figure out by itself what to compile.
Of course, when one unit's interface changed, every unit that
depends on it (directly or indirectly) must be recompiled.
> Here's the contents of that post:
> I was trying to fix my linking problems, when I ran into a possible
> reason why --automake or --autobuild isn't doing its thing for me.
> Its seems that if the .gpi file is not present for a unit, it won't
> compile that unit in, but rather stops saying that that unit could
> not be compiled, eg.
> module/unit `ghj_aaclustergroups' could not be compiled
This message appears if either the source is not found or
compilation failed because of some error.
> This means the first time around I'm force to compile the lot myself.
> I've sort-of ducked by this using gpc -c *.pas a few times.
> Thinking about it, is this because the compiler can't guess the
> filename holding the unit, given that the unit name is assigned
> within the file?
> If so, a possible extension would be to do one scan of all *.pas and
> *.p files at the onset and compile a table of unit/module names for
> each file and proceed from there? Or perhaps this is what it already
> does and something else is afoot?
Nope. What it does is to assume file name = interface name
(+ suffix), unless you specify `uses ... in 'filename''. Well, this
is documented (in the references under `uses', and in the
This probably doesn't explain the problem above (it should't fail to
create .o files, without giving any errors). For that I'd still need
Frank Heckenbach, frank at g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
More information about the Gpc