|
From: John K. <jk...@sa...> - 2003-06-22 17:54:21
|
On Sun, 2003-06-22 at 12:58, Bruce Smith wrote: > > The kernel is only being compiled for different CPU's, the applications > > are being compiled for 486. > > > > Reason, the tool chain in the LFS system was built for 486 compilation > > and this will be the default -march. To fix this all build scripts will > > have to add to the gcc options a -march=<CPU>. Adding this would be > > easier during ./configure. eg. CFLAGS= -march=686; ./configure > > <options>. And of course it would be very nice if the 686 came from a > > shell variable set by the DL config file. > > > > Now I could still be wrong about this, and someone coming back and > > calling me a moron ;-), but one thing that could be happening is an > > environment variable could be set that sets the default -march for > > gcc??? Maybe Heiko would know the answer to this? But in all the gnu > > toolchains that I've built I've never seen documented that the default > > arch can be controled by an enviornment variable, but the gcc manual is > > pretty thick. > > We could find out for sure if there was some way to determine what arch > a pre-compiled binary was compiled for. (I could check my i686 compiled > DL and see). Except I don't know of any way to tell. Does anyone know > of a way to tell? I thought that using readelf would do it but it's displaying the same machine info for DL compiled binaries for a 486 and binaries compiled on my Mandrake which is compiled for i586. If you do a readelf -a <binary name> you'll see at the very top of the listing elf header information. One of the lines has. "Machine : Intel 80386" I would assume that this is where the -march=???? should go but doesn't appear to. It's always 80386. > > > Now a comment that could make this entire discussion mute is compiling > > the kernel from a 486 to a 686 makes a huge difference on the system. > > But what are you really gaining by changing the applications from a 486 > > to 686 compiles??? > > For some applications it would make no difference. But it can make a > big difference for some packages. For example almost all programs use > glibc extensively, so it will help a lot there. And it can help > stand-alone programs which are CPU intensive, like OpenSSL. > > We could go through and modify the few packages it would help and forget > the rest (like Redhat does on their distribution). Or do everything. > I agree that it would affect some applications. If we do some packages then when lets keep in mind that one day all of them would be done too.. Obviously starting with the packages that would have the most affect, can you think of any others packages other then glibc and openssl? > - BS > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner. > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > Devil-linux-develop mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-develop -- John Kiss <jk...@sa...> |