Re: [PATCH,cygming,buildsys] Fix remaining parts of PR40125: [1/2] libgcc

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 21/01/2011 10:04, Paolo Bonzini wrote:
> On 12/23/2010 10:57 PM, Dave Korn wrote:
>> That's fine for a native compiler, but for a cross-compiler, the DLLs
>> built are target libraries, not host ones. It doesn't make sense to
>> install them in $prefix/$target/bin, because that contains host binaries.
>> What does make plenty of sense however is to install them somewhere under
>>  $prefix/$target/lib, since that is chock-full of target binaries
>> already, libraries in particular, and following some discussion in the PR
>> audit trail we decided toolexeclibdir was the right place.
>>
>> The attached patch implements this by defining a new SHLIB_xxx variable
>> to pass in libgcc.mvars that contains the name of the install directory, 
>> either bindir or toolexeclibdir; this is set by choosing one of two 
>> t-makefile frags in config.gcc. It also adds the standard stanza for
>> computing toolexeclibdir in libgcc's configure, as the definition wasn't
>> yet available there.
> 
> The patch is okay, however it is a bit ugly.

  Given time pressure, committed as it stands at r.169274.

> Would you investigate moving the shared library definitions to 
> libgcc/config/t-slibgcc-cygming, where you can simply use
> 
> ifeq ($(host), $(target))
> SHLIB_DLLDIR = $(bindir)
> else
> SHLIB_DLLDIR = $(toolexeclibdir)
> fi
> 
> instead of the multiple fragments?

  Isn't libgcc like other target libs in that host always == target when it's
being built?  It appears that way to me.  I think I'd have to import
with_cross_host into the makefile to be able to use it in a makefile frag
there, which is why I went for the choose-a-frag-in-gcc-configure approach in
the first place...

    cheers,
      DaveK