On Mon, Jun 6, 2022 at 3:04 PM DustDFG <[email protected]> wrote: > > On Mon, Jun 6, 2022 at 12:31 PM Matías Fonzo <[email protected]> wrote: > > > > El 2022-06-06 08:04, DustDFG escribió: > > > On Sat, Jun 4, 2022 at 10:38 PM Matías Fonzo <[email protected]> wrote: > > >> > > >> El 2022-06-03 23:52, DustDFG escribió: > > >> > On Fri, Jun 3, 2022 at 4:46 PM Matías Fonzo <[email protected]> wrote: > > >> >> > > >> >> El 2022-06-03 04:47, DustDFG escribió: > > >> >> > On Thu, Jun 2, 2022 at 6:49 PM Matías Fonzo <[email protected]> > > >> >> > wrote: > > >> >> >> > > >> >> >> El 2022-06-02 09:29, DustDFG escribió: > > >> >> >> > Hello Matias! > > >> >> >> > > > >> >> >> > I apologize for coming back to this > > >> >> >> > > > >> >> >> > On Thu, Apr 28, 2022 at 7:00 PM Matias Fonzo <[email protected]> > > >> >> >> > wrote: > > >> >> >> >> > > >> >> >> >> El 2022-04-27 04:12, DustDFG escribió: > > >> >> >> >> > Hi, > > >> >> >> >> > > > >> >> >> >> >> No, I was talking about to modify the output of packages by > > >> >> >> >> >> default > > >> >> >> >> >> (from Qi), but first I want to check if we can just include > > >> >> >> >> >> the > > >> >> >> >> >> packages > > >> >> >> >> >> in a ISO handling the category name in the packages, for > > >> >> >> >> >> e.g: all the > > >> >> >> >> >> @core.tlz packages for the ISO (CD 1). > > >> >> >> >> > > > >> >> >> >> > I think that if we don't worry about size of this iso image, > > >> >> >> >> > it doesn't > > >> >> >> >> > look like > > >> >> >> >> > a problem because we can use 'find' utility. I still can't > > >> >> >> >> > understand > > >> >> >> >> > what > > >> >> >> >> > you > > >> >> >> >> > mean. What does modification of packages by default means? > > >> >> >> >> > > >> >> >> >> The size of the ISO matters, since we have to create the images > > >> >> >> >> for > > >> >> >> >> several CDs, in 700mb maximum. To achieve this you have to > > >> >> >> >> adjust or > > >> >> >> >> change the output of the packages for the files containing the > > >> >> >> >> build > > >> >> >> >> orders. For example, the packages generated from 00-core.order > > >> >> >> >> would > > >> >> >> >> be > > >> >> >> >> installed to /var/cache/qi/packages/cd1/ with the rest > > >> >> >> >> continuing to > > >> >> >> >> wrap their output for the next CD number. So from stage 2 you > > >> >> >> >> can > > >> >> >> >> create > > >> >> >> >> the images for the CDs. It also gives the possibility of doing > > >> >> >> >> what > > >> >> >> >> you > > >> >> >> >> suggested before, once the packages are generated, they will be > > >> >> >> >> available in the packages/ directory, when chrooting in, Qi can > > >> >> >> >> be > > >> >> >> >> used > > >> >> >> >> to install directly, for example. the core from > > >> >> >> >> var/cache/qi/packages/cd1. > > >> >> >> >> > > >> >> >> >> Apart from this, my proposal is to create a rootfs, which you > > >> >> >> >> unpack > > >> >> >> >> directly, which is more direct and faster than having to install > > >> >> >> >> packages one by one via Qi. > > >> >> >> >> > > >> >> >> > > > >> >> >> > What do you think the rootfs must contain? > > >> >> >> > > >> >> >> The rootfs can contain whatever the final system produces, usually > > >> >> >> everything (packed in a tar.gz). > > >> >> >> > > >> >> >> > > >> >> > > > >> >> > It will be a big file. Why not tarlz? > > >> >> > > >> >> Because tar/gzip is more widely supported, and some laptops > > >> >> (Chromebooks, if I'm not mistaken) only support this format (to be > > >> >> loaded in a SD card), I don't know if other formats are supported. > > >> >> > > >> >> > I also want to ask you about temporary system. Can we pack it like a > > >> >> > cross-compiler? > > >> >> > > >> >> I don't recommend it, since they contain the hard-coded paths to > > >> >> fulfill > > >> >> its purpose, a prior step ensuring that the final system build will > > >> >> not > > >> >> be contaminated by host system stuff. > > >> >> > > >> >> > > >> > > > >> > Is it only tools directory? > > >> > > >> Yes, exactly. This does not represent a running system (with a kernel > > >> image, etc.) but it is about temporary tools to build the final > > >> system. > > >> > > > > > > I tried to understand what depends on hard coded paths but I couldn't > > > do it. In every place we know where is tools directory. I can't > > > understand why we need link to tools directory and what depends on it. > > > Could you explain it, please? > > > > It is enough to do a `grep tools stages/1/*` to know what depends on > > /tools. Both the installation of tools and the dynamic linker are going > > to look through this path, in order to isolate the host system, mainly > > the isolation of the C library with respect to the system in which you > > run with the system you want to build. This is somewhat documented[1] > > and done by projects such as Linux From Scratch[2]. > > > > From [1]: > > > > " > > The overall goal of Chapter 5 and Chapter 6 is to produce a temporary > > area that contains a known-good set of tools that can be isolated from > > the host system. By using chroot, the commands in the remaining chapters > > will be contained within that environment, ensuring a clean, > > trouble-free build of the target LFS system. The build process has been > > designed to minimize the risks for new readers and to provide the most > > educational value at the same time. > > " > > > > [1] > > https://linuxfromscratch.org/lfs/view/development/partintro/toolchaintechnotes.html > > [2] https://linuxfromscratch.org/lfs/ > > > > > > It seems to me that gcc has linker option -rpath...
Ok. I didn't think -rpath won't have sense. First of all, I want to say that I understand why we need tmp system but I can't understand where it depends on something that we can't pack like darkcrusade. After processing stage 1 we get tmp system that depends on itself only. Yes, we need host system to run it (with chroot) but we can move it to another system. It is self-contained like darkcrusade compilers. Where am I wrong?
