Gentoo Archives: gentoo-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Cross Compilation and Dynamic Slots
Date: Wed, 11 Aug 2004 14:18:33
In Reply to: Re: [gentoo-dev] Dynamic SLOTs by Jason Stubbs
1 On Tuesday 10 August 2004 23:55, Jason Stubbs wrote:
2 > No Grand Unified Theory of Everything yet, but ...
3 Almost there!
5 I'll summarise the list of requirements that I see and then go through how
6 they can solve various problems with regards to ${SUBJECT}.
10 Defines a set of atoms that must be on the host system to be able to
11 compile for this profile.
12 bashrc - available as of portage-2.0.51_pre17
13 ARCH, USERLAND, LIBC & KERNEL are defined as those required for the
14 package that is about to be compiled when sourced. Bashrc should define
15 aliases for the toolchain to define how to compile for the host
16 specified with a system of this profile.
19 cat/pkg&keyword
20 Defines that a package needs to be compiled as the specified keyword.
21 Portage expands the keyword to ARCH, USERLAND, LIBC & KERNEL and passes
22 those to the host profile's bashrc. If an atom does not specify a
23 keyword, it is taken to be that of the target root's profile.
24 cat/pkg{atom [atom]}
25 The braced atom specifies extra bounds for a matching cat/pkg's DSLOT.
28 DSLOT="atom [atom ...]"
29 Portage scans installed and to be installed packages against the
30 specified atom(s) and builds the DSLOTted package once for each
31 individual package match, passing the matched package name to the
32 ebuild in the DSLOT variable.
33 pkg_select()
34 This function configures the system to use this package by default. If
35 it is successful or if there is no need to do so, it should return 0.
36 It should also export any information needed to revert the system back
37 to its original state. If it is not successful, it should do any
38 cleanup required immediately and return 1.
39 pkg_revert()
40 This function reverts the system to back to the state it was in before
41 running pkg_select() based on information exported by pkg_select().
44 /var/db/pkg/keyword/cat/pkg-ver[--pkg-ver]
45 The keyword is taken or inferred from the cat/pkg&keyword specified for
46 the installed package. The [-pkg-ver] component represents the DSLOTted
47 version of the package.
49 Not too much I hope... Anyway, on to how I envision it working.
54 DEPEND would simply contain "net-www/apache" without respect to USE flags as
55 well as any other DEPENDs it might have. DSLOT would also contain
56 "net-www/apache". Apache doesn't need to do any special setup and so would
57 simply return a 0 for both pkg_select() and pkg_revert(). In the case that
58 both apache-1.3.31-r2 and apache-2.0.50 are installed, portage would elect to
59 install mod_php twice, passing in the different versions of apache each time.
60 Each installation would end up in a directories under /var/db/pkg labelled
61 mod_php-4.3.8--apache-1.3.31-r2 and mod_php-4.3.8--apache-2.0.50.
63 As for differing use flags, users could specify them in package.use using the
64 new atom syntax. For example, "dev-php/mod_php{=apache-2*} -mysql". Users
65 could also restrict the combination by way of package.mask. If they wanted
66 both apache-1 and apache-2 installed but only wanted mod_php for apache-2,
67 for example, a user could specify "dev-php/mod_php{=apache-1*}" in
68 package.mask and so on and so forth.
72 The only required change would be DSLOT="virtual/linux-sources" as the ebuild
73 already detects what kernel version is at /usr/src/linux and compiles against
74 it. The kernels, on the other hand, would define pkg_select() to change the
75 linux symlink to its own sources and export what was previously linked. Then
76 in pkg_revert() it would restore the symlink to its original state.
80 The only other that I know of, ocaml, could use the pkg_select() function to
81 run ocaml-config to set the compiler to the version required. Any package
82 that needs to be slotted based on the version of another package should be
83 able to be done so in pretty much the same way.
85 GCC
87 To build a cross compiler, the atom would be "sys-devel/gcc&keyword". Gcc
88 would then receive the keyword in the form of ARCH, USERLAND, LIBC & KERNEL
89 but would still be able to tell the host architecture by way of the keyword
90 'USE flag'. Portage would then slot the compiler into /var/db/pkg/keyword/.
91 Gcc would also define pkg_select() and pkg_revert() to do the same as ocaml.
95 A "chroot" would be created and the profile set. Any other files (such as
96 make.conf, et al) would also be created before any emerging starts. The
97 profile then dictates what tools are required from the host by way of
98 In a sparc profile, for example, would be "sys-devel/gcc&sparc".
99 Portage would then emerge gcc into the host system as specified above.
101 When packages are to be merged into the "chroot", portage will look at the
102 and run pkg_select() on each tool required before doing the
103 compilation and merging and then run pkg_revert() after each.
107 I'll use amd64 as the example. In the profile, bashrc would set aliases
108 defining how to run gcc to create 32bit binaries when ARCH="x86". The
109 profile's ACCEPT_KEYWORDS would be "amd64 x86". When keyword matching is
110 done, they are search in order of ACCEPT_KEYWORDS and the first match is used
111 when sourcing bashrc and when recording the installation into the installed
112 package database.
114 Any packages that the to be installed package depends on will then be
115 installed using the accepted keyword.
118 I'm sure there are a few issues remaining here. I think that most of them will
119 be much easier to deal with, though. Feedback is greatly welcome.
121 Regards,
122 Jason Stubbs
124 --
125 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Cross Compilation and Dynamic Slots "Ilya A. Volynets-Evenbakh" <iluxa@g.o>