serious libgcc regression added recently

From: David Miller <davem@davemloft.net>
Date: Wed, 02 Nov 2011 18:43:52 -0400 (EDT)

> So t-softmul gets appended anyways, and this causes us to try and
> build config/sparc/lb1spc.S for the 64-bit libgcc which we should
> never do.

I tried the patch below but it just results in syntax errors in the
Makefile.

Is this the way differences between multilib cases are going to be
handled now in libgcc, with these backtick shell conditionals that (of
all things) looks at the destination directory?

What if I want to put 64-bit libraries in a different location such as
plain 'lib/' to create a 64-bit pure system or similar?

I definitely prefer how this stuff worked beforehand wherein we would
know the actual "target" we're building for and we bring in the
appropriate "target" makefile fragments based upon that "target".

Now we just seem to look at the host and essentially include every
possible target makefile that could be multilibbed out of that host.

On Wed, Nov 2, 2011 at 4:28 PM, David Miller <davem@davemloft.net> wrote:
> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
> +                       = x../lib64; then echo sparc/lb1spc.S; fi`
> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
> +                       = x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`
>

-print-multi-directory is most likely easier to handle than os-directory.

Thanks,
Andrew Pinski

On Wed, 2 Nov 2011, David Miller wrote:

> Is this the way differences between multilib cases are going to be
> handled now in libgcc, with these backtick shell conditionals that (of
> all things) looks at the destination directory?
> 
> What if I want to put 64-bit libraries in a different location such as
> plain 'lib/' to create a 64-bit pure system or similar?

See my review <http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02288.html> 
suggesting a followup to improve on the logic that was carried from the 
gcc/ directory.

> I definitely prefer how this stuff worked beforehand wherein we would
> know the actual "target" we're building for and we bring in the
> appropriate "target" makefile fragments based upon that "target".

Previously, makefile variables in the gcc/ directory had to be set just 
once and could not depend on the multilib, only on the target triplet - 
hence the `` code.

Now, because the variables are set in the libgcc directory which is 
configured separately for each multilib, it is possible for the makefile 
fragment selected to depend on the multilib as well as the target triplet, 
in a way it couldn't before.  This is a clear improvement.

Note that all these patches were posted at least two months ago with calls 
for testers, so there was plenty of time for target maintainers to review 
and test them for their targets.

From: Andrew Pinski <pinskia@gmail.com>
Date: Wed, 2 Nov 2011 16:40:13 -0700

> On Wed, Nov 2, 2011 at 4:28 PM, David Miller <davem@davemloft.net> wrote:
>> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
>> +                       = x../lib64; then echo sparc/lb1spc.S; fi`
>> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
>> +                       = x../lib64; then echo _mulsi3 _divsi3 _modsi3; fi`
>>
> 
> -print-multi-directory is most likely easier to handle than os-directory.

I was just copying the construct Rainer was already using in
sparc/t-linux64 :-)