more on ffast-math and gcc-4.1.1 (and finally fixed)

Kevin Day thekevinday at gmail.com
Mon Aug 21 16:06:04 PDT 2006


On 8/20/06, Robert Connolly <robert at linuxfromscratch.org> wrote:
> I still can't get uClibc working with gcc-4.1.1. Everything linked to uClibc
> crashes, including main(){}. I used the patches below, along with patches
> from uClibc.org (buildroot). I also tried building with -Os and -O2.
>
> robert
>


Well, I could give you all of my patches to gcc and uclibc.
I have done so many "unusual" or different things that it may be quite
hard to find what it is that I am doing different that allows me to
build it.

So, what I can do is give you my scripts for uClibc & gcc, the
uclibc.conf files, and all relating patches, but for the sake of those
with limited bandwidth (or mailbox space) I'd much rather send it
directly to you.

Currently, I am searching for what is causing the remaining
abort/segfaults on my system.
There seems to be some form abort that happens.  I cannot get gdb to
produce anything usable as it gets locked up or crashes in the same
manner (perhaps building gdb into the toolchain as static would be a
better approach)

As far as I can tell, it seems that when a program would want to do
deallocation, or large amounts thereof, this abort seems to occur.  I
have come to believe this as a large number of programs crash with an
abort immediately before they exit, or in the case of Wesnoth, when a
scenario/mission is finished (which is the perfect time to start
calling deallo quite a few times).

I see three possible places, gtk, uClibc, and gcc.
Gcc-4.1.* clearly has its problems, but I am not sure this is not the
direct cause, and it may in fact be a catalyst at this point. (but
then again, it may be opposite).

uClibc in my opinion may have some problem with the segfaults as I
have in the past made a number of my problems go away by switched
between their allocation/deallocation methods. (they have three and
all three are undocumented to what they truly due and what their
purpose is intended for).  However, when switching the alloc/dealloc
in uclibc I fix some problems and create new ones.  As best as I can
tell, all three are full of bugs or the way in which many applications
attempt to use these are buggy.

gtk+ 2.10.3 has been found as a direct cause of a number of segfaults,
which is clearly worse than getting an abort, due to the security
issue.  I have have to go back to gtk+2.8.? in order to remove this
segfault.  As most of the applications that abort are graphical I see
it as a high possibility that whatever gtk+ 2 is doing, it is doing
something wrong, and they are doing it even worse in newer versions.

As far as SSP/LDNOW and all the other uClibc security features, I have
had no problems enabling them under uClibc+gcc-4.1.?, but I never got
around to test if it is actually doing anything.

I have recently turned off the security features to see if any of the
aborts are being caused by it.

I have also removed the --with-pic from my global configure script
flags, to see if anything changes.

I have not tried -fpie/-fPIE yet, which may be what is causing your
failures to compile or run. I have been hoping to stabalize as much as
I can before switching to that so I can isolate as many non-pie
problems from pie problems.

Also, I seem to have recursively built my systems off the same
gcc-4.1.1 over and over again, each time fixing problems (or
attempting to).  My initial gcc-4.1.1 system had no security enabled
whatsoever.  I eventually created the possible SSP enabled system
under a system compiled from gcc-4.1.1.  So, perhaps the reason why I
got this to work in the manner that I did was from my bootstrapping.

Some more notes on how non-standard (even for hlfs) my system is:
- I currently have NLS completely disabled, I plan to work it back in
eventually, but I've noticed problems regarding that, and with it
disabled I have been running on a console system using only 10Megs of
Ram, and in Xorg (complete modular install), at say 1280x1024 with
WindowMaker+Docklets using only 27Megs of Ram.  Turning it back on
might have caused it to up to 40Megs of Ram in Xorg and 20 or 30 in
console. (but I have made more than one change per system-compile pass
so other changes may have been the cause)
- I am currently using a couple of linux kernel patches, including
that of the increased random thing (the name evades me), I am using
the maximum settings of 1024->2048.
- I have gone against my word and starting to directly use kernel
headers (patched to reflect  all patches I would apply for a running
kernel). I now use scripts to extract/patch/move kernel headers from
raw kernel source of the version I intend the system to run on.
- I have moved all of my GCC-stuff to a seperate directory so I can
compress and delete the system compiler without damaging any other
system file.  (thus I get the /toolchain directory which is where I
store all of my files that are needed for compilation in any manner
(.la files, header files (yes I modified gcc for that as well),
automake and the like)
- What I use that may have the biggest effect are the exact settings
of my current uClibc config file. For everything that can be
overridden at make/make install time, I have replaced with
"SCRIPT_ME_AWAY" or something like that..
- I am still using the old method, not the embryo method.  I do not
want to change as I am extremely close to stabilization that I do not
want to risk screwing anything up yet.  After I feel my systems are
stable enough, I will try your embryo method.

I'll try to figure out what I did differently that is causing me to
work and you to not work.
-- 
Kevin Day



More information about the hlfs-dev mailing list