To segfault or not to segfault..

Kevin Day drealin01 at cox.net
Sun Jun 18 14:22:29 PDT 2006


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.




More information about the hlfs-dev mailing list