[PATCH,cygming,buildsys] Fix remaining parts of PR40125: [1/2] libgcc
Dave Korn
dave.korn.cygwin@gmail.com
Wed Jan 26 07:53:00 GMT 2011
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
More information about the Gcc-patches
mailing list