[PATCH] top-level for libvtv: use normal (not raw_cxx) target exports

[Michael Haubenwallner]

On 06/19/2015 11:36 AM, Paolo Bonzini wrote:
> On 09/06/2015 16:22, Michael Haubenwallner wrote:
>> Hi build machinery maintainers,
>>
>> since we always build the C++ compiler now, I fail to see the need to still
>> use RAW_CXX_TARGET_EXPORTS for libvtv.
>>
>> The situation to expose the problem is:
>> * Use a multilib-enabled x86_64-linux box.
>> * Use a 64-bit (multilib-disabled) bootstrap compiler (binary image).
>> $ configure --enable-multilib --with-system-zlib
>> $ make bootstrap
>>
>> When it comes to build the 32-bit libvtv, it breaks because of using
>> "CC=/build/prev-gcc/xgcc -m32" "CXX=g++ -m32", while it should use
>> "CC=/build/prev-gcc/xgcc -m32" "CXX=/build/prev-gcc/xg++ -m32" instead.

Unfortunately, I've been unable to reproduce this problem for a while now,
and it turns out that I also used --enable-maintainer-mode. And it happens
only when some generated autotool-file is updated while it is in use - not
really sure which one though, probably some configure script.

But still:

>> However, I'm not sure about the general question behind:
>> Should it work to bootstrap the multilib-compiler using a non-multilib one?
>>
>> This also needs above configure flags to work around two more but minor issues,
>> which I'm unsure about whether I can/should fix at all:
>> * --enable-multilib: Without this, the "user friendly check" is breaking,
>>     since https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=205975
> 
> Why is it breaking?

The OS I'm running on is a multilib-enabled x86_64 (Gentoo) Linux,
and "32-bit development libraries (libc and headers)" are available.

The compiler I want to bootstrap the multilib compiler with is an
x86_64-only binary image (c,c++,ada), built _without_ multilib.

Now this "user friendly check" tries to create a 32-bit executable using
that 64-bit-only bootstrap gcc, which lacks 32-bit libgcc* - while it
can create 32-bit object files though.

>> * --with-system-zlib: Without this, --enable-multilib tries to build a
>>     32-bit zlib with "CC=/build/32/./prev-gcc/xgcc"
> 
> Ouch, that's a separate bug...  Arguably --with-system-zlib should be
> the default these days (and should have been for 10 years or so).

This one I'll leave untouched.

> The patch is ok.

Even if the problem raises only because maintainer-mode isn't multilib-save?

Thanks!
/haubi/