Re: Building same package twice and package forking

Stefan Fiedler wrote:
> Am Sonntag, 12. November 2006 10:52 schrieb Luca:
> ...
>   
>> LFS uses for toolchain a unique "stage" (in which binutils and gcc are
>> built twice) and then begins the building of the final bare system; in
>> Cross-LFS there is a stage for cross-compile tools only which are used
>> for the next stage to build the "temporary" toolchain system used to
>> build the final cross-lfs system (and obviously the options passed to
>> configure and make are different for the two passes -example in clfs
>> gcc-pass1 configures only support for c while in pass2 languages
>> supported are c and c++).
>>     
> ...
>   
>> Greetings,
>> Luca
>>     
>
> Hi Luca!
>
> ROCK Linux does basically the same.
> In native builds, as well as in cross builds, gcc and binutils are build in 
> stages 0 and 1; this roughly equals LFS first and second pass.
> In stage 0 (wether native or cross), packages are not installed to the final 
> chroot environment, but to other directories 
> (build/<build-id>/ROCK/tools.{chroot,native,cross}/); some 'magic' in the 
> build scripts makes sure that the toolchain installed in these directories is 
> used in stage 1 (and also that e.g. the cross toolchain is used for cross 
> builds).
> There's also the $stagelevel build variable that makes e.g. gcc packages build 
> only the C compiler if [ $stagelevel == 0 ] (which again is similar to LFS 
> pass 1).
> Packages built in stage 1 to 9 are installed in the (final) chroot 
> environment; In stage 2 and onwards the chroot environment is entered and the 
> toolchain contained within is used.
> In ROCK Linux cross builds, most packages are built in stage 1, after gcc & co 
> (here the build priority becomes important). It might help to consider stage 
> 1 after gcc and co. as stage 1.5; another piece of code ensures that the 
> 2nd pass gcc from stage 1 is used as soon as it has been built.
>
> Bottom line:
> If you want to e.g. change how gcc 2nd pass builds, adapt 
> package/base/gcc/gcc.conf so that your changes are effective if [ $stagelevel 
> == 1 ]. Similarily, use [ -n "$pkg_gcc_cross" ] for cross builds.
>
> Btw. there's no explicit Adjusting the Toolchain phase;  this is done in 
> various places in the build scripts. Don't hesitate to ask if you can't find
> some peculiar piece of code.
>
> Given your example, instead of creating a package/base/gcc/preconfig.in, you 
> could add the following lines to package/base/gcc/config-300.in:
> 	pkgfork gcc gcc-pass1 stages 012--5---9 priority 101.000
> 	pkgfork gcc gcc-pass2 stages 012--5---9 priority 101.000
> immediately above
> 	pkgremove gcc
> (Note copy&pasting your example did _not_ work here; there is some problem 
> related to whitespace - using tabs and spaces only fixes this...)
>
> Also you can use
> 	pkgenable <package>
> to enable packages e.g. in target/<target>/config.in. Use pgkdisable, 
> pkgremove accordingly.
>
> It looks like a bug that gcc-pass{1,2} from your example are built in stages 7 
> and 8... this hasn't shown up before, but if it is reproducable, and is a 
> problem for you, it should be fixed.
>
> Hope that helps,
> 	Stefan Fiedler
>
>   
Hi Stefan and good morning to you and everyone!

Thanks for your replay and feedback as well as of other persons.

I tried by passing those stages options to the forks only to see if
(looking at the package selection list) I understood and managed package
forking (it was obviously only a try because it's a non-sense to build
forks used only one or two time/s in the stages of a final system).
In using the $stagelevel I have no real problems related.

I'm actually talking to the team of the Official LFS LiveCD about
porting lfs targets to ROCK scripts and I was explicitly told that for
using this way to create Bootable or Installations CDs/DVD isos and/or
final systems to claim it, for example, a "secondary" Official LFS CD I
had to make it work and build the same way the project does.

For the copy and paste probably something went wrong in the mail formatting.

I don't actually understood one thing about forking:
let's take the example I did about the gcc forks (with some minor
adjustments):

pkgfork gcc gcc-pass1 stages 01-------- priority 101.000
pkgfork gcc gcc-pass2 stages 01-------- priority 101.000

If, for example, gcc not forked is being built only in native stages,
let's say:
" stages --2--5---9 priority 150.000 "
is it really necessary to add the "pkgremove gcc" below the declaration
of the forks?

Again, thanks for help and feedback and have a nice day to everyone!

Yours,
Luca