When I first built the gcc-4.1.0 system of mine, I got nothing but
segfaults.
Much like the problems Robert mentioned.
However, I was under the impression that they were related to my
differences. I have since knocked out most of the segfault issues and
even gotten more programs to work. But, up until this week, I have
been using workaround and hacks. My last couple of posts have been
actual fixes, but here are the differences between what I am using and
what Robert might/might not be using.
First off, I mentioned -ffast-math at some point.
-ffast-math seems to be a gcc-4.1.? problem. -ffast-math is a major
cause of segfaulting on the uClibc+gcc-4.1 system.
I am not sure whether it is a uClibc + gcc-4.1.? problem or just a
gcc-4.1 problem. Either way, to prevent the system from randomly
segfaulting, REMOVE ALL USES OF -ffast-math from all projects.
Here is a list of what I have found to include -ffast-math and my
"fixes" for them:
DirectFB:
sed -i -e 's|-ffast-math||g' $(find $PWD -name Makefile)
libogg:
sed -i -e 's|-ffast-math||g' configure
libvorbis:
sed -i -e 's|-ffast-math||g' configure
libao:
sed -i -e 's|-ffast-math||g' configure
vorbis-tools:
sed -i -e 's|-ffast-math||g' configure
libmikmod:
sed -i -e 's|-ffast-math||g' configure
xvidcore:
sed -i -e 's|-ffast-math||g' configure
procps:
procps-3.2.6-gcc41-1.patch
Mesa:
sed -i -e 's|-ffast-math||g' Makefile.{DJ,mgw} \
progs/samples/Makefile.{DJ,mgw} progs/samples/Makefile.{DJ,mgw} \
configs/{linux*,darwin,freebsd*,sunos*}
If there are any others, then I missed them and their segfault issues
were slightly evasive I donot use MPlayer, but the time in which I
installed it, it assumed all of the system-specifc flags, so It
probably does use -ffast-math
--------
Another possible cause for segfaulting is -fpie and -fPIE; however, this
may be my fault through some unnoticed mistakes. I have never had a
system with -fpie and -fPIE not segfault since day 1 with HLFS.
Given that nobody else had issues and reported them, suggesting I was
making mistakes. Up until this week I have been building systems
without any hardening flags (SSP & PIE) to help isolate my problems.
I did, however, pass -fpic -fPIC whenever possible in every single
location, so my system may no longer have non-PIC code.
I have finally worked myself to an PIC+SSP system, but I will not move
to PIE anytime soon.
No segfaults presented, so if I were to add pie, new segfault issues
might be revealed
------
Now, I have other differences between my system and that of Robert's
HLFS. I will point out those that I feel are most relevant.
my uClibc is VERY different, I am getting away with uClibc-0.9.28 +
binutils-2.16.1 + gcc-4.1.1.
I have two passes to make on the target system, see my other recent
posts about the order.
The first pass has the config file with the following notable
differences:
UCLIBC_STATIC_LDCONFIG=y
- This is needed for the first pass of the bootstrap for
uClibc/gcc. This way no /tools files get inside my /lib files. Perhaps
I am a little paranoid here..
UCLIBC_HAS_STDIO_BUFSIZ_8192=y
- I noticed that vim uses the built-in buffer size in some manner
to store copied data, increasing this to 8192 will help vim and other
programs get a more useful buffer size (less truncating of data)
UCLIBC_PRINTF_SCANF_POSITIONAL_ARGS=10
- I accidently ran into a program that checks to make sure the
glibc position args is what it should be. It checked for >= 10. So it
seems that 10 would be better to have for glibc compatibility
Security Options:
UCLIBC_SECURITY=y - for SSP
# SSP_QUICK_CANARY is not set
# SSP_USE_ERANDOM is not set
# UCLIBC_BUILD_PIE is not set
# PROPOLICE_BLOCK_SEGV is not set
# PROPOLICE_BLOCK_KILL is not set
# UCLIBC_BUILD_SSP is not set
UCLIBC_HAS_SSP=y - for SSP
PROPOLICE_BLOCK_ABRT=y - for SSP
The second pass has the following changes:
# UCLIBC_STATIC_LDCONFIG is not set
- I prefer not to use static ldconfig
UCLIBC_BUILD_RELRO=y - for security
UCLIBC_BUILD_NOW=y - for security
UCLIBC_BUILD_NOEXECSTACK=y - for security
Now, for some target system difference:
When setting up a system, say chapter 6.6, the following symlinks
were used by me instead of what is mentioned there: ($TO = /tools,
$TA=/mnt/hlfs) ln -vfs $TO/bin/{bash,cat,pwd,perl} $TA/bin
ln -vfs $TO/bin/stty $TA/bin
ln -vfs $TO/bin/bash $TA/bin
ln -vfs $TO/bin/env $TA/bin
ln -vfs bash $TA/bin/sh
ln -vsf $TO/lib/crt{1,i,n}.o /lib - this is what is done in order
to get gcc to compile for me.
(libgcc_s.so is not linked at this point, as the book does)
After fooling around with gcc, I noticed that the configure script
checks for gmp. I felt safe to added it immediately before second pass
of gcc.
----
Now, more segfaulting DOES occur when the gcc+uClibc+binutils system is
not bootstrapped. This happens because --print-specs file does not
exist, so the instructions do absolutely nothing to make gcc stop using
the toolchain (/tools).
This further becomes an issue with m4 and bison. The m4 seems to link
to the /tools, because bison is found in the /tools. Bison depends on
m4 and m4 depends on bison..So bootstrapping bison/m4 is necessary as
well.
1) install bison
2) install m4 after bison (circular dependancy)
3) After m4 is installed, re-install bison to link against the proper
m4.
--
http://linuxfromscratch.org/mailman/listinfo/hlfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
