Bug 17601 - gcc/Makefile.in: Setting up XX_FOR_TARGET does not work
Summary: gcc/Makefile.in: Setting up XX_FOR_TARGET does not work
Status: RESOLVED WORKSFORME
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 3.4.3
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-22 09:21 UTC by Ralf Corsepius
Modified: 2015-12-10 14:06 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-01-11 00:00:00


Attachments
Proposed patch (356 bytes, patch)
2004-09-22 09:51 UTC, Ralf Corsepius
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Corsepius 2004-09-22 09:21:50 UTC
gcc/Makefile.in applies the construct below to setup various XX_FOR_TARGET make
variables:
..
AR_FOR_TARGET = ` \
  if [ -f $(objdir)/../binutils/ar ] ; then \
    echo $(objdir)/../binutils/ar ; \
  else \
    if [ "$(host)" = "$(target)" ] ; then \
      echo ar; \
    else \
       t='$(program_transform_name)'; echo ar | sed -e $$t ; \
    fi; \
  fi`
..

Apparently, this does not work when building a cross compiler (here
sparc-rtems4.7) on FC2/i386:
..
# cd build/gcc
# make
..
make[1]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc3.4.3newlib1.12.0/build/gcc'
for d in libgcc soft libgcc/soft v8 libgcc/v8 soft/v8 libgcc/soft/v8; do \
  if [ -d $d ]; then true; else /bin/sh ../../gcc-3.4.3/gcc/mkinstalldirs $d; fi; \
done
if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi
rm -rf ./libgcc.a
` if [ -f
/users/rtems/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc3.4.3newlib1.12.0/build/gcc/../binutils/ar
] ; then echo
/users/rtems/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc3.4.3newlib1.12.0/build/gcc/../binutils/ar
; else if [ "i686-redhat-linux-gnu" = "sparc-unknown-rtems4.7" ] ; then echo ar;
else t='s,^,sparc-rtems4.7-,;'; echo ar | sed -e  ; fi; fi`  rc ./libgcc.a
libgcc/./_mulsi3.o libgcc/./_divsi3.o libgcc/./_modsi3.o libgcc/./_muldi3.o
libgcc/./_negdi2.o libgcc/./_lshrdi3.o libgcc/./_ashldi3.o libgcc/./_ashrdi3.o
libgcc/./_cmpdi2.o libgcc/./_ucmpdi2.o libgcc/./_floatdidf.o
libgcc/./_floatdisf.o libgcc/./_fixunsdfsi.o libgcc/./_fixunssfsi.o
libgcc/./_fixunsdfdi.o libgcc/./_fixdfdi.o libgcc/./_fixunssfdi.o
libgcc/./_fixsfdi.o libgcc/./_fixxfdi.o libgcc/./_fixunsxfdi.o
libgcc/./_floatdixf.o libgcc/./_fixunsxfsi.o libgcc/./_fixtfdi.o
libgcc/./_fixunstfdi.o libgcc/./_floatditf.o libgcc/./_clear_cache.o
libgcc/./_enable_execute_stack.o libgcc/./_trampoline.o libgcc/./__main.o
libgcc/./_absvsi2.o libgcc/./_absvdi2.o libgcc/./_addvsi3.o libgcc/./_addvdi3.o
libgcc/./_subvsi3.o libgcc/./_subvdi3.o libgcc/./_mulvsi3.o libgcc/./_mulvdi3.o
libgcc/./_negvsi2.o libgcc/./_negvdi2.o libgcc/./_ctors.o libgcc/./_ffssi2.o
libgcc/./_ffsdi2.o libgcc/./_clz.o libgcc/./_clzsi2.o libgcc/./_clzdi2.o
libgcc/./_ctzsi2.o libgcc/./_ctzdi2.o libgcc/./_popcount_tab.o
libgcc/./_popcountsi2.o libgcc/./_popcountdi2.o libgcc/./_paritysi2.o
libgcc/./_paritydi2.o libgcc/./_divdi3.o libgcc/./_moddi3.o libgcc/./_udivdi3.o
libgcc/./_umoddi3.o libgcc/./_udiv_w_sdiv.o libgcc/./_udivmoddi4.o
libgcc/./_pack_sf.o libgcc/./_unpack_sf.o libgcc/./_addsub_sf.o
libgcc/./_mul_sf.o libgcc/./_div_sf.o libgcc/./_fpcmp_parts_sf.o
libgcc/./_compare_sf.o libgcc/./_eq_sf.o libgcc/./_ne_sf.o libgcc/./_gt_sf.o
libgcc/./_ge_sf.o libgcc/./_lt_sf.o libgcc/./_le_sf.o libgcc/./_unord_sf.o
libgcc/./_si_to_sf.o libgcc/./_sf_to_si.o libgcc/./_negate_sf.o
libgcc/./_make_sf.o libgcc/./_sf_to_df.o libgcc/./_sf_to_tf.o
libgcc/./_thenan_sf.o libgcc/./_sf_to_usi.o libgcc/./_usi_to_sf.o
libgcc/./_pack_df.o libgcc/./_unpack_df.o libgcc/./_addsub_df.o
libgcc/./_mul_df.o libgcc/./_div_df.o libgcc/./_fpcmp_parts_df.o
libgcc/./_compare_df.o libgcc/./_eq_df.o libgcc/./_ne_df.o libgcc/./_gt_df.o
libgcc/./_ge_df.o libgcc/./_lt_df.o libgcc/./_le_df.o libgcc/./_unord_df.o
libgcc/./_si_to_df.o libgcc/./_df_to_si.o libgcc/./_negate_df.o
libgcc/./_make_df.o libgcc/./_df_to_sf.o libgcc/./_df_to_tf.o
libgcc/./_thenan_df.o libgcc/./_df_to_usi.o libgcc/./_usi_to_df.o
libgcc/./unwind-dw2.o libgcc/./unwind-dw2-fde.o libgcc/./unwind-sjlj.o
libgcc/./gthr-gnat.o libgcc/./unwind-c.o libgcc/./_eprintf.o libgcc/./__gcc_bcmp.o
sed: option requires an argument -- e

AFAIS, the $$t in
t='$(program_transform_name)'; echo ar | sed -e $$t ;

expands to an empty string instead of the correct sed pattern, whic causes the
Makefile to break.
Comment 1 Ralf Corsepius 2004-09-22 09:51:06 UTC
Created attachment 7194 [details]
Proposed patch
Comment 2 Andrew Pinski 2004-09-22 12:24:28 UTC

*** This bug has been marked as a duplicate of 16503 ***
Comment 3 Andrew Pinski 2004-10-04 03:37:40 UTC
Reopening as this the other bug is for RTL problem but this one is for the makefile problem (I made the 
mistake as the reporter of that bug should have opened a different bug for the makefile problem).
Comment 4 Andrew Pinski 2004-10-04 03:40:04 UTC
       t='$(program_transform_name)'; echo ar | sed -e $$t ; \

This is right, I don't understand how it can go wrong, unless I don't understand makefile/shell 
interactions.
Comment 5 Ralf Corsepius 2004-10-04 04:09:15 UTC
(In reply to comment #4)
>        t='$(program_transform_name)'; echo ar | sed -e $$t ; \
> 
> This is right, I don't understand how it can go wrong, unless I don't
> understand makefile/shell interactions.
I don't understand either, the contruct above works in ordinary shell scripts,
but apparently doesn't work inside of the Makefile.

However, as 
echo <tool>|sed '$(program_transform_name)
is used at other places (e.g. gcc/Makefile.in, gcc/configure.ac), I am proposing
to consistently use the same construct for setting up XX_FOR_TARGET, too (cf.
attachment).




Comment 6 Alexandra Kossovsky 2006-08-03 14:12:54 UTC
I've got this bug when building cross compiler gcc-3.4.6 on i686-linux for x86_64-linux on Debian Sarge system.
Thanks to Ralf Corsepius for his patch.
Comment 7 Richard Biener 2012-01-11 12:31:52 UTC
Is this still an issue?
Comment 8 Ralf Corsepius 2012-01-11 14:03:55 UTC
(In reply to comment #7)
> Is this still an issue?

This BZ is such kind old, I would not have remembered it ;)

Anyway, I've built RTEMS toolchains many hundred times since then without any patch related to this issue applied.

So my guess is this BZ has "magically been healed", now is obsolete and can be closed.
Comment 9 Bernd Schmidt 2015-12-10 14:06:33 UTC
Closing based on last comment (which I'll interpret as the submitter saying WORKSFORME).