Pierre Labastie wrote:
On 22/06/2016 19:52, Bruce Dubbs wrote:
Pierre Labastie wrote:
On 21/06/2016 21:12, Bruce Dubbs wrote:
Pierre Labastie wrote:
The place where /tools/ is added before /lib is in 5.10, GCC Pass 2. it is
the long sequence of instructions starting with "for file in". Have you
pasted those instructions from the book, or did you recopy them by hand?
Make sure you have the line
----------------
sed -e 's@/lib\(64\)\?\(32\)\?/ld@/tools&@g'
----------------
right. If you have just the slightest typo, the files are not modified
(and there is no warning...).
Now that you mention it Pierre, I think the following would be better
because it is far easier to read and understand. [...]
We could use -r 's@/lib(..)?/ld@/tools&@g' to cover /lib/ld.
seems OK
I prefer not using what 'man 7 regex' calls Obsolete ("basic") regular
expressions. Otherwise there are too many backslashes that interfere with
understanding what is going on. The equivalent in grep is using the -E option
or egrep.
agreed
Actually, the regexp in the book is matched by many files
gcc/config/sparc/linux64.h
gcc/config/sparc/linux.h
gcc/config/rs6000/linux64.h
gcc/config/rs6000/sysv4.h
gcc/config/mn10300/linux.h
gcc/config/vax/linux.h
gcc/config/bfin/linux.h
gcc/config/s390/linux.h
gcc/config/mips/linux.h
gcc/config/xtensa/linux.h
gcc/config/i386/linux64.h
gcc/config/i386/linux.h
gcc/config/cris/linux.h
gcc/config/nios2/linux.h
gcc/config/m68k/linux.h
gcc/config/frv/linux.h
gcc/config/microblaze/linux.h
gcc/config/ia64/linux.h
gcc/config/tilepro/linux.h
gcc/config/m32r/linux.h
gcc/config/linux.h
gcc/config/tilegx/linux.h
gcc/config/sh/linux.h
We should be hesitant in changing instructions that have worked for so long,
but the only files that should affect us are those that begin with
gcc/config/i386/
The only files that have lib32 are:
gcc/config/mips/linux.h
gcc/config/tilegx/linux.h.
The ones that match lib64 are:
gcc/config/mips/linux.h
gcc/config/sparc/linux64.h
gcc/config/i386/linux64.h (one place)
gcc/config/rs6000/linux64.h
The find for sysv4.h should be irrelevant for us.
I realize that the files have changed a lot since our instructions have been
written... It seems that s@/usr@/tools@ is not needed anymore, because
the paths are now relative (to what, I am not sure. But at least they are not
absolute). OTOH, it is hard to know whether and where the instructions about
STARTFILE_PREFIX are needed...
$ grep -rl STARTFILE_PREFIX *
gcc/config/vms/xm-vms.h
gcc/config/i386/mingw32.h
gcc/config/i386/nto.h
gcc/config/i386/xm-djgpp.h
gcc/config/ia64/hpux.h
gcc/config/openbsd.h
gcc/config/netbsd.h
gcc/config/mips/st.h
gcc/config/mips/mti-linux.h
gcc/config/mips/mips.h
gcc/config/spu/spu-elf.h
gcc/config/darwin.h
gcc/config/pa/pa-hpux11.h
gcc/config/pa/pa64-hpux.h
gcc/config/pa/pa-hpux10.h
gcc/ChangeLog-2002
gcc/ChangeLog-1997
gcc/ChangeLog-2004
gcc/ChangeLog-2009
gcc/ChangeLog-2007
gcc/ChangeLog-1998
gcc/ChangeLog-2008
gcc/FSFChangeLog.10
gcc/ChangeLog-2010
gcc/ChangeLog
gcc/ChangeLog-2015
gcc/doc/tm.texi.in
gcc/doc/gccint.info
gcc/doc/tm.texi
gcc/ChangeLog-2001
gcc/gcc.c
gcc/config.gcc
gcc/ChangeLog-2014
gcc/Makefile.in
gcc/ChangeLog-1999
gcc/ChangeLog-2000
gcc/ChangeLog-2005
gcc/FSFChangeLog.11
gcc/ChangeLog-2003
Of those, the only files that might relevant are
gcc/config/i386/nto.h
gcc/config/i386/xm-djgpp.h
gcc/gcc.c
gcc/config.gcc
So I thing appending the entries is still needed in headers, except only
for gcc/config/i386/linux{,64}.h
That would make the chunk
for file in gcc/config/i386/linux{,64}.h; do
cp -uv $file{,.orig}
sed -r 's@/lib(..)?/ld@/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
That's a tiny bit less confusing, but I don't really know that it makes a
significant difference from what we have.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Do not top post on this list.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
http://en.wikipedia.org/wiki/Posting_style
