LinuxQuestions.org - against recommendations on 64bit compilation of certain packages...

- Linux From Scratch (https://www.linuxquestions.org/questions/linux-from-scratch-13/)

- - against recommendations on 64bit compilation of certain packages... (https://www.linuxquestions.org/questions/linux-from-scratch-13/against-recommendations-on-64bit-compilation-of-certain-packages-235792/)

against recommendations on 64bit compilation of certain packages...

Does anyone know why is not recommended to compile the critical linux packages like binutils, gcc and glibc with optimizations or a specific target?

maybe because... you lose the ability to cross-compile?
or is it a more strange or cryptic reason?

As posted before, I'm going for the 64 bit versions of linux but at least I would like to know why the LFS book encourage not to do that optimizations... creepy :scratch:

Julio

I always though it was because those packages could behave badly. Some code can behave differently with different optimizations.

Code:

#include <stdio.h>



main()



{

        int number;



        printf("%d\n", number);

}

gcc a.c && ./a.out
gives me an answer of 1073827936

gcc -O2 a.c && ./a.out
gives me an answer of 1

This is with gcc 2.95.3, 3.3.3 and 3.4.2. It is a rather silly coding mistake to make but it is an example of different results for different -O levels.

The reason optimisations have not been recommended in the past is mainly due to the support questions that arise when people push things too far ( -O3 -fcrazy-shit ).

None of this is really relevant for 64bit builds though.

For 64bit builds you need a toolchain which targets 64bit, using this toolchain to compile glibc
et al you don't need to generally supply any extra flags.

You can usually get away with supplying -mtune= and -march= ( if you so desire )

At some point in the next few weeks I'll be updating cross-lfs in preparation for merging into
lfs-unstable ( http://www.linuxfromscratch.org/~rya...pts/cross-lfs/ ), it should give you an
idea on how to build your 64bit system (be it uni-arch or bi-arch 32/64 )

New scripts should be up for testing ~20041004

Quote:

The reason optimisations have not been recommended in the past is mainly due to the support questions that arise when people push things too far ( -O3 -fcrazy-shit ).

well... no intention on using -O3 or any other optimization for now... maybe -fomit-frame-pointers, as I don't want to have extra registers allocation for pointer frames... but O3... not sure... seems not an option for my first attempt to build the basic system tools... I'll better use O3 for GNOME applications... I think it's a better option, what do you think? ;)

Quote:

None of this is really relevant for 64bit builds though.

For 64bit builds you need a toolchain which targets 64bit, using this toolchain to compile glibc
et al you don't need to generally supply any extra flags.

You can usually get away with supplying -mtune= and -march= ( if you so desire )

that's an option I considered to use, but if GCC manual is correct (and I suppose it is), -mtune is a deprecated synonym for -cpu, so I think I only need to put -march=athlon64 to be able to optimize code generation for my CPU, although I'm not sure If I must use that in conjuntion with -mcpu=athlon64 as the manual says it's more or less the same...

Quote:

it should give you an
idea on how to build your 64bit system (be it uni-arch or bi-arch 32/64 )

not sure about this... pure 64bit system is the ideal state... but I suppose not every piece of software willl work fine in 64bit mode... or can I have any chances of compiling... for example... the GNOME desktop in 64bit? or maybe... X11 or... at least... the GIMP? :D

Julio

Quote:

Originally posted by ParticleHunter
not sure about this... pure 64bit system is the ideal state... but I suppose not every piece of software willl work fine in 64bit mode... or can I have any chances of compiling... for example... the GNOME desktop in 64bit? or maybe... X11 or... at least... the GIMP? :D
Julio [/B]

Lol, some of the most important stuff is 32bit ;-)
RtCW, UT2k[34] and (soon on linux) Doom 3 ;-)

hahahaha you're right... but if I want a mixed architecture, what packages can I compile in 64bit and which ones not?

Julio

P.D. and you forget the most important... Quake3 :D

For mixed architecture you firstly need a bi-arch toolchain.

Then you generally build any packages which provide
libraries twice, first time 32bit ( CC=gcc -m32 ),
second time 64bit (ensures you have 64 bit binaries, but
both 32bit and 64bit libraries).

Care has to be taken that 64bit libraries are installed to
*/lib64
(generally all that is required is passing --libdir=/blah/lib64 )

thought UT2K3/4 had 64bit versions... :scratch:

well... I'll try to make first a 64bit LFS uni-arch and later... maybe i'll redo all passes and make a mixed 64/32 LFS

;)

Julio

by the way...

doesn't building a mixed system means that the CPU will run in 'hybrid' mode? :scratch:

(definitely, I think for my first test I will build a 'pure' 64bit system... step by step ;))

Julio

Quote:

Originally posted by mdh
....
New scripts should be up for testing ~20041004 [/B]

Not to be pushy or anything, but are those scripts up yet? And will they be based on the LFS-6.0-testing version?
Anyway, I'm in the process of setting up a biarch LFS (32bit / x86_64 ), and would really like to use and/or test your newest versions.

If you have something pretty much ready to go, please let me know.
Thanks,

Ben.

Apologies, was AFK yesterday :-/
New scripts will be up in end of today.

Scripts aren't based on any particular book version, it should build for whatever package
versions you specify. Note my focus is predominately toolchain, you may want to go over
the scripts for non-toolchain components and edit to taste.

They will be under http://www.linuxfromscratch.org/~rya...pts/cross-lfs/

[R]

Thanks man, I appriciate it :p !
Once they are up I will give it a go and post my results!

Ben.

New scripts are up. (v3.0.3)

Let me know how you go...

You may want to consider joining the lfs-hackers mailing list if you need any help with them, I'll respond quicker there than here ;-)

Note: documentation is pretty much non-existent, but the scripts are pretty well commented...

Best Regards
[R]