Grant Jacobs gjacobs at
Mon Mar 3 23:24:55 CET 2003

At 1:22 PM +0100 3/3/03, Frank Heckenbach wrote:
>Grant Jacobs wrote:
>>  1. The compiler won't make .o files for units that are found in a
>>  directory other than the one you're compiling from.
>>  I have three directories and I compile from within one of them. The
>>  units in the other two directories are located using --unit-path
>>  compiler option. Reading the docs, I'm under the impression its
>>  supposed to default to placing the .o files into the directory you
>>  compile from for all units,
>Yes, I think that's how it should be (and seems to be in my test).
>>  regardless where the units are located
>>  unless you play with the compiler options. The .gpi files *are* made
>>  correctly. (I'm using --autobuild, btw.)
>Sorry, but your description is not really clear to me. Are no .o
>files created, or in which directories are they created, and what
>about the gpi files? Which compiler options did you use, and which
>files are located where?

No .o files are made for nits which lie outside the current 
directory. You have to do them yourself manually, which in my case is 
simply a matter of 'gpc -c ../otherdir/*.p'. However, its not what I 
expected. I thought the compiler would locate them via --unit-path 
which I use on the command line, etc.

alias  gpc="gpc --executable-file-name --nested-comments 

(Excuse the wraparound.) I compile from 

The units in GHJLibraries and table_code_dir have their .gpi files 
made into aa_prog_dir as expected; but no .o files are made for these 
units. .o files are made for all the units in aa_prog_dir, but not 
the other two directories.

I can work around it, but it might be worth noting as something that 
might be tackled "one day".

>  > 2. (Less important: I suspect this will resolve itself once the above
>>  issue is dealt with.) The linker its looking for a lot of init_*
>>  references, which I presume are initialisation routines. The docs
>>  indicate that units don't need to supply an initialisation part. Does
>>  linker simply "do away" with these references, or are empty
>>  initialisation routines required?
>The problem is that while compiling the interface, it is not known
>whether the unit has an initialisation part (or any variables that
>need initialization, or uses any units that have an initializer,
>...). So if you wanted to convey the information whether there's one
>to the user of the unit, the GPI file would have to be updated
>Even worse, with circular unit references (which I don't like, but
>we have to support them), things get even trickier. I could
>construct some example if you really care ...
>AFAICS, improving it would cost much effort and gain very little
>(the costs of a redundant empty initalizer is almost always

Leave it. This looks more trouble than its worth.

Grant Jacobs Ph.D.                                     BioinfoTools
ph. +64 3 476 1820  (office, after 10am)               PO Box 6129,
or  +64 25 601 5917 (mobile)                               Dunedin,
gjacobs at                               NEW ZEALAND.
    Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
Check out the website for more details:

The information contained in this mail message is  confidential and
may  be legally privileged. Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination, 
distribution or reproduction of this message is prohibited. If  you
have received this message in error please notify the sender immed-
iately and destroy the original message.  This applies also to  any
attached documents.

More information about the Gpc mailing list