g++/stl -frepo problem? (was: library renaming due to changed libstdc++ configuration)

[Miles Bader <miles@gnu.org>]

I wrote earlier
> I've noticed that with recent updates, I'm suddenly getting tons of
> undefined function errors resulting from STL-related template
> instantiation.  [I've attached an example at the end of this message.]

Er, any comments on this?  It's driving me nuts that I now can't compile
my program... but I can't find any obvious problem with what I'm doing.
As the problem started pretty much exactly with the latest g++/libstdc++
upgrades, I wonder...

Summary of problem:  compilation with g++ gives "undefined reference"
for references to some STL template function instantiations, despite
using -frepo (which AFAIK should automatically recompile something to
instantiate all missing functions).  [See previous message for some
error output.]

I've explored this problem further since my original message, which has
yielded a bit more info:

  + The missing methods have "O " lines in various .rpo files, and the
    source for the methods (e.g., std::vector<...>::_M_insert_aux) is
    available in the header files; as I understand it, -frepo should
    cause the linker to pick one of the files that lists a missing
    method in its .rpo file, and recompile it to instantiate the
    function and change the .rpo entry to "C " -- but it doesn't seem to
    be doing this (though it apparently used to).

  + Whether it works or not actually seems to depend on the order with
    which entries are put into the .rpo files:  I have some old .rpo
    files left around (from before the recent libstdc++ changes), and if
    I recompile using these as a "base" (they get updated during
    compilation of course), then the compilation succeeds!!  However if
    I then type "make clean" and recompile everything, linking fails.
    [Could this be a collect2 bug?]

  + When using google to search for reports of similar problems, I saw
    that in the past such symptoms could result from having multiple
    versions of libstdc++ installed; I've made sure I only have one
    (libstdc++6-4.0-dev version 4.0.2-4, and libstdc++6 version 4.0.2-4).

  + I've had the same problem on two different machines (both of which
    track unstable but have a somewhat different collection of packages
    installed).

Should I report this as a bug against g++?

[I've tried, but failed to find a concise test case; however there's no
problem to share my source code if someone wants to debug this, and I
can supply the "make it work" old versions of my .rpo files that I
mentioned above.]

If this is simple user error, I apologize for all the noise.

Thanks,

-Miles
-- 
x
y
Z!