-frepo problems

David Mazieres dm@reeducation-labor.lcs.mit.edu
Fri Jan 8 15:08:00 GMT 1999


I am using various versions of egcs on OpenBSD 2.4.  Versions of egcs
on which I have explicitly tested this bug report with similar results
include:

   gcc version egcs-2.92.34 19990108 (gcc2 ss-980609 experimental)
   gcc version egcs-2.92.23 19981125 (gcc2 ss-980609 experimental)
   gcc version egcs-2.91.57 19980901 (egcs-1.1 release)

Basically, the -frepo flag never seems to cause recompilation at link
time.  For example, when compiling the attached program, I get:

% c++ -v
Reading specs from /usr/local/egcrap/lib/gcc-lib/i386-unknown-openbsd2.4/egcs-2.92.34/specs
gcc version egcs-2.92.34 19990108 (gcc2 ss-980609 experimental)
% c++ -frepo -c dumbrepo.C && c++ -frepo dumbrepo.o
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
collect2: ld returned 1 exit status

On Solaris, by comparison, the exact same command line with another
recent version of egcs gives:

collect: recompiling dumbrepo.C
collect: relinking

and a working a.out file.

One possible clue is that the .rpo file generated under OpenBSD does
not demangle properly.  The vtable symbol is missing an underscore.
For example, on OpenBSD:

% c++ -frepo -c dumbrepo.C && c++filt < dumbrepo.rpo 
M dumbrepo.C
D /home/am2/dm/hack/egcs-bugs
A '-frepo' '-c'
O printer<1>::_cl(void) const
O _vt$t7printer1i1
% nm -u dumbrepo.o | c++filt
___main
printer<1> virtual table
% nm -u dumbrepo.o | tail -1 ; tail -1 dumbrepo.rpo
__vt$t7printer1i1
O _vt$t7printer1i1

Thus, the vtable symbol in the .rpo file appears to be missing an
underscore.  I don't know what the .rpo file format is supposed to be,
but certainly on Solaris the symbol in the .rpo file actually matches
the mangled name for the vtable.

If I manually edit the .rpo file on OpenBSD, it actually makes
collect2 try a recompile, though .rpo file reverts and the link
consequently fails.  For instance:

% c++ -frepo -c dumbrepo.C
% perl -pi -e 's/^O _vt\$/O __vt\$/' dumbrepo.rpo
% tail -1 dumbrepo.rpo 
O __vt$t7printer1i1
% c++ -frepo dumbrepo.o 
collect: recompiling dumbrepo.C
collect: relinking
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
dumbrepo.o: Undefined symbol `printer<1> virtual table' referenced from text segment
collect2: ld returned 1 exit status
% tail -1 dumbrepo.rpo 
O _vt$t7printer1i1

So there you have it.  I hope this is enough information for a
diagnosis, even though the bug obviously does not apply to all
platforms.

Thanks,
David

===

#include <stdio.h>

template<int n>
struct printer {
  virtual void operator() () const { printf ("%d\n", n); }
};

int
main ()
{
  printer<1> p;
  p ();
  return 0;
}



More information about the Gcc-bugs mailing list