On 8/20/06, Robert Connolly <[EMAIL PROTECTED]> 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 -- http://linuxfromscratch.org/mailman/listinfo/hlfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
