> I believe that C++ tests pick the correct bits/c++config for
> -m32. Can't libitm do something similar?
The problem is that the -I for the build is chosen at the toplevel,
*before* iterating over the multilibs, whereas the -I for testing is
chosen in dejagnu, *after* iterating over the multilib
On Thu, Nov 3, 2011 at 10:57 PM, Richard Henderson wrote:
> We currently have a problem building libitm because it uses the libstdc++
> header , and the toplevel Makefile passes a single set of
> include paths for all multilibs. In the recent merges from mainline, we
> brought in changes to that
On 11/04/2011 05:32 AM, Joseph S. Myers wrote:
> It would be fixed by staged install ...
Yeah, I thought of that too. Maybe for 4.8...
r~
If libstdc++ has multilib-specific headers, which one gets installed?
How will anything be able to use those headers from an installed tree?
On Nov 4, 2011, Richard Henderson wrote:
> I can't imagine there's a quick fix, but I'd be delighted to be proven
> wrong.
I don't have a patch yet, but IMHO the correct and quick-ish fix would
be in config-ml.in: get it to apply the same transformation to CC et al
that it applies at configure
On Thu, 3 Nov 2011, Richard Henderson wrote:
> I've worked for 2 days to try to work out what our Makefile does. It
> seems completely and totally broken to me. I can't imagine there's a
> quick fix, but I'd be delighted to be proven wrong.
It would be fixed by staged install (install into a te
