Problem with TU identification: separate compilation bug

[Valentin Bonnard]

egcs needs a way to uniquely identify a translation unit.

The version I have just tested 

Reading specs from
/usr/local/util/packages/egcs-050798/lib/gcc-lib/sparc-sun-solaris2.5/egcs-2.91.45/specs
gcc version egcs-2.91.45 19980704 (gcc2 ss-980609 experimental)

uses a local path to the file (a previous one used another 
system).

In a separatly compiled program, egcs will be invoked 
several times.

First let me say that I assumed that, it's for the invocations
to take place in different directories, as in:

cd D1
egcs -c f.cc
# creates f.o
cd ..
egcs g.cc D1/f.o
# creates a.out
a.out

But if you do that, egcs might think that two TU are 
the same because it uses the path to the file _from 
the directory where it is invoked_. 

A fix for this problem would be to use the complete path, 
beginning at /. However, James Kanze wrote:

> You can't really use the full path; I
> can build a library in my home directory on one machine, and use
> it with code developed in my home directory ("/home/kanze" in both
> cases) on another, so the problem is the same as filenames.  

So this isn't perfect either.

Another solution would be to go back to the previous system: 
a TU is identified by the signature first non inline external 
function definition.

But this isn't sufficient either, because the TU may not 
have one. In this case you could ignore the TU completly, 
but this could break existing programs (such programs relly 
on implementation defined behaviour anyway, and are therefor 
unportable).

James also wrote:

> You can't use a time stamp, since with
> many people working on the same project.  You can't even really
> use the fully qualified domaine -- most PC users don't have one.

and proposes a solution:

> (Quite frankly, I'd hack it, and just generate a 256 bit random
> number.  With a good randomizing function, collisions should be
> really rare, and of course, if you recompile, the collision
> disappears.  So even a user who stumbles onto the "bug" won't
> be able to reproduce it.)

-- 

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/