On 09/11/2018 14:30, Pierre Labastie via lfs-dev wrote:
On 09/11/2018 13:38, John Frankish via lfs-dev wrote:
Ref:

Linux From Scratch - Version SVN-20181029 Chapter 5. Constructing
a Temporary System 5.5. GCC-8.2.0 - Pass 1

Using the latest script to update the dynamic linker results in gcc failing to build.

Using a previous script fixes the problem.

Details below.



This script:

for file in gcc/config/{linux,i386/linux{,64}}.h
do
   cp -uv $file{,.orig}
   sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g' \
       -e 's@/usr@/tools@g' $file.orig > $file
   echo '
#undef STANDARD_STARTFILE_PREFIX_1 #undef
STANDARD_STARTFILE_PREFIX_2 #define STANDARD_STARTFILE_PREFIX_1
"/tools/lib/"
#define STANDARD_STARTFILE_PREFIX_2 ""' >> $file
     touch $file.orig
done

This script has been in the book for a couple of years. It is hard
to believe that nobody else has seen a failure if it is wrong.

Maybe your system is not recognized as either i386 or x86_64, or not as linux?

Are you building on a Mac, Unix derivate or raspberry pi? What is
the response of the " arch" command?

I'm building on a linux machine recognised as x86_64 and I tried
three separate times...

Could it be a copy/paste artifact, such as a space after '\' at the
end of a line?
GNU_TARGET_OS_etc is defined in gcc/config/linux.h, and shouldn't be
modified by the said script; unless possibly if there is a typo.
Sorry if I sound like the error comes from your side (script, our
unusual system, I rule out LFS and LFS_TGT variable settings, since it
seems to work with the old script), but really, after 2 years,
somebody should have spotted the same error as you.

I don't think that the new script has been in use as much as two
years, since I last built using the LFS instructions a year ago with the old script.
This being said, yes, you would have thought that somebody else would
have noticed it.

It could be a copy paste error, but I tried three times with the new
script and it worked first time when copy pasting the old script...

As an aside, what is the first line of the current script meant to expand to?

$ for file in gcc/config/{linux,i386/linux{,64}}.h

gcc/config/linux/linux.h
gcc/config/linux/linux64.h
gcc/config/i386/linux.h
gcc/config/i386/linux64.h

..gcc/config/linux is not present in the gcc-8.2.0 source

Has coreutils always been able to deal with double {{}} or is a new(er) version required?

Ah - my problem is here:

$ for file in gcc/config/{linux,i386/linux{,64}}.h
do
echo $file
done
gcc/config/{linux,i386/linux{,64}}.h

$ for file in gcc/config/linux.h gcc/config/i386/linux.h gcc/config/i386/linux64.h
do
echo $file
done
gcc/config/linux.h
gcc/config/i386/linux.h
gcc/config/i386/linux64.h

Hmmm, is your host using bash? I just tried dash, and I get:
$ for file in gcc/config/{linux,i386/linux{,64}}.h
> do echo $file
> done
gcc/config/{linux,i386/linux{,64}}.h

If your system is debian-like, try "sudo dpkg-reconfigure dash"


Hmm, sorry, I see that your system is tinycore64. AFAICS, there is no dash shell in tinycore (unless you compiled it). It seems to have only bash... But maybe it is a stripped down version of bash, not interpreting double {. Or maybe you are using busybox shell (testing it on debian shows it does not interpret the double {).

Pierre


--
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to