Menu
▾
▴
devil-linux-develop
|
From: John K. <jk...@sa...> - 2003-06-22 16:34:33
|
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. 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??? On Tue, 2003-06-17 at 18:18, Heiko Zuerker wrote: > Bruce Smith wrote: > >>>>Take a look at scripts/prepare and search for "uname" ( without the > >>> > >>>quotes > >>> > >>>>*lol*). The complete DL System is build for the specific CPU. > >>> > >>>Are you sure it's working? I was watching openssl & glibc both compile > >>>on my screen, and I never say anything that looked like: -march i686 > >>>or any gcc parameter containing "686" (except for the kernel). > >> > >>Hmmm.....checking...checking.....checking....executing: ./scripts/build.sh > >>build opt=openssh > >>Ok, the host-type and build-system-type in the configure part is correct, > >>but I don't see any -march=686 either. > >>Question: doesn't gcc use the architecture it was compiled for, when you > >>don't specify anything? > > > > > > I don't know. I'm far from being a gcc expert. > > same here > > >>I'm getting a bit confused now.... > > > > > > Welcome to the club! :-) > > > > I've been reading the gcc man page, looking at gcc.gnu.org docs, and > > searching the newsgroups. > > > > The most useful thing I found so far is "gcc -v" tells what "spec" file > > it uses for default options. I looked at that file, but all the fancy > > substitution stuff is over my head. > > > > It may be using i686 optimization (in my case), but I don't know how to > > confirm or deny it. > > Let's hope somebody on this list has the answer to this. > > cya > Heiko > > > > ------------------------------------------------------- > 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...> |
|
From: Heiko Z. <he...@zu...> - 2003-06-22 18:00:20
|
John Kiss 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. The build system includes the build of it's own gcc. When I check the build/tmp/gcc-build directory, I'll see a folder i686-pc-linux-gnu . I would expect that *this* gcc is for i686 and compiles everything which isn't specified differently for i686. Long sentence short: the default -march should be (in this case) 686, correct? > 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 define CFLAGS as an environment variable, but some programs just don't care about it. > 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??? I agree with Bruce, just the Kernel is not enough. cya Heiko |
|
From: Bruce S. <bw...@ar...> - 2003-06-22 16:58:45
|
> 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? > 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. - BS |
|
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...> |
|
From: Bruce S. <bw...@ar...> - 2003-06-22 20:27:07
|
> > 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. Yes, that doesn't work. I tried it on the same program I compiled two different ways. It displays the same for both. I suppose we could specifically compile one with -march=i686 and again without any -march options, and compare the two binaries. > > 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? I used those two as examples because Redhat supplies multiple arch's for those RPM's. I suppose anything that does encryption or a lot of math could use it. OpenSSH, all the VPN packages, gnupg, ... - BS |
|
From: Bruce S. <bw...@ar...> - 2003-06-17 19:58:24
|
> >In menuconfig, submenu: "Build System Configuration", there is an option > >that allows you to select your CPU. I've been building all of my betas > >as i686 because my home firewall is a celeron. > > > >It _appears_ the CPU option only effects the kernel compile... > > *beep* wrong ! ;-) Not the first time, or the last! :-) > Take a look at scripts/prepare and search for "uname" ( without the quotes > *lol*). The complete DL System is build for the specific CPU. Are you sure it's working? I was watching openssl & glibc both compile on my screen, and I never say anything that looked like: -march i686 or any gcc parameter containing "686" (except for the kernel). Not to mention the comment near "uname", only says "kernel". :-) # fake uname to display another platform we want to compile the kernel And, yes, I doubled checked my .config file: CONFIG_CPU=686 - BS |
