1 |
On Monday 12 October 2009 15:49:48 Thomas Sachau wrote: |
2 |
> Mike Frysinger schrieb: |
3 |
> > On Sunday 16 August 2009 08:37:37 Thomas Sachau wrote: |
4 |
> >> -for the portage version: It is also in the multilib overlay, but in a |
5 |
> >> different branch called portage-multilib. To use this, you should read |
6 |
> >> the instructions at [1] (doc/portage-multilib-instructions). This one |
7 |
> >> should also mainly work, but there is probably a good amount of packages |
8 |
> >> in the main tree, which may refuse to work with it. |
9 |
> > |
10 |
> > the abi-wrapper doesnt look terribly appealing. why dont we use |
11 |
> > broken/custom -config handling as incentive to convert packages to .pc |
12 |
> > files. pkg-config handles ABI/cross-compile splitting cleanly and |
13 |
> > transparently. |
14 |
> |
15 |
> I am totally unfamiliar with pkg-config, so that would take some time or a |
16 |
> helping hand. |
17 |
|
18 |
going by the pkg-config wrapper we use for cross-compiling, the multilib code |
19 |
should unset: |
20 |
PKG_CONFIG_ALLOW_SYSTEM_CFLAGS |
21 |
PKG_CONFIG_ALLOW_SYSTEM_LIBS |
22 |
|
23 |
then it should export export PKG_CONFIG_LIBDIR to the ABI-specific pkgconfig |
24 |
dir. so it should be something akin to: |
25 |
export PKG_CONFIG_LIBDIR=/usr/$(get_libdir)/pkgconfig |
26 |
|
27 |
any package that adds things to PKG_CONFIG_PATH (grep /etc/env.d/) will be a |
28 |
problem here, but it seems only qt-3 currently falls into this category. the |
29 |
easiest thing will probably be to just disallow this behavior completely. |
30 |
|
31 |
then pkg-config should automatically locate the right abi-specific .pc files |
32 |
and filter the related abi-specific flags. |
33 |
|
34 |
> > bash-4 is stable, so we could start depending on it. |
35 |
> |
36 |
> It still has 3 unstable KEYWORDS including mips. |
37 |
|
38 |
mips doesnt count -- it's moving all to ~arch, and you've counted the bsd |
39 |
arches which are never stable (currently). |
40 |
|
41 |
> > you dont save/restore CPPFLAGS |
42 |
> |
43 |
> Are there any initial values it should get? |
44 |
|
45 |
the current profiles dont set any, but it should be treated as a precious |
46 |
toolchain variable same as any other compiler flag |
47 |
|
48 |
another quick look at _setup_abi_env() looks like it needs work: |
49 |
- LD should not default to `ld` |
50 |
- the -L paths to system dirs in LDFLAGS should not be there -- the toolchain |
51 |
can handle these just fine |
52 |
- missing CPPFLAGS handling |
53 |
- see previous comments re-pkg-config |
54 |
- you dont declare pyver local |
55 |
- the abi if check is uncommon syntax. "! [[ a == b ]]" -> "[[ a != b ]]" |
56 |
|
57 |
> > is there documentation that covers the proposed changes/design to portage |
58 |
> > ? i'm not looking for high level (it runs src_compile twice). i dont |
59 |
> > recall seeing details posted to the portage or gentoo mailing lists ... |
60 |
> > it's hard to review `git diff portage-svn..master`. |
61 |
> |
62 |
> There is currently no documentation for the actual code version. |
63 |
|
64 |
what about documentation for ebuild writers ? only thing i see is how to |
65 |
install the new version of portage. |
66 |
|
67 |
> In short, there are those changes: |
68 |
> |
69 |
> 1. ability to run phases multiple times in ebuild.sh: |
70 |
> |
71 |
> change from |
72 |
> ... |
73 |
> dyn_unpack() |
74 |
> src_unpack |
75 |
> |
76 |
> dyn_compile() |
77 |
> src_compile |
78 |
> |
79 |
> dyn_install() |
80 |
> src_install |
81 |
> ... |
82 |
> |
83 |
> to basicly |
84 |
> |
85 |
> ... |
86 |
> dyn_unpack() |
87 |
> for each ABI |
88 |
> call set_abi |
89 |
> create ABI workdir |
90 |
> set ABI envronment variables |
91 |
> call src_unpack |
92 |
> |
93 |
> dyn_compile() |
94 |
> for each ABI |
95 |
> call set_abi |
96 |
> use workdir for current ABI |
97 |
> set ABI environment variables |
98 |
> call src_compile |
99 |
> |
100 |
> dyn_install() |
101 |
> for each ABI |
102 |
> call set_abi |
103 |
> use workdir for current ABI |
104 |
> set ABI environment variables |
105 |
> call src_install |
106 |
> call _finalize_abi_install |
107 |
> create gentoo-multilib headers (if needed) |
108 |
> ... |
109 |
|
110 |
so basically what we already do in like glibc and sandbox. at the base level, |
111 |
should be fine since it's been working so far with these few ebuilds. |
112 |
|
113 |
how do you control whether the multilib headers are needed ? it'll probably |
114 |
make sense in general, but there are def some packages where this will only |
115 |
get in the way (the toolchain ones). |
116 |
|
117 |
how do you differentiate between packages where multi ABIs make no sense ? |
118 |
for example, most packages that dont install any libraries but just binaries. |
119 |
let's use the simple package app-text/tree. |
120 |
|
121 |
a lot of this multilib code should probably continue to live in the tree as |
122 |
it's a pretty big base of code to formalize that could do with fixes over |
123 |
time. i.e. we figure out that certain paths / define protections dont work so |
124 |
well, so changing them to something else would require PMS changing !? there |
125 |
has been talk before about pushing a lot of basic stuff to the tree so things |
126 |
dont have to be encoded in the PMS. |
127 |
|
128 |
how are packages handled that can only be used via 1 ABI ? any of the |
129 |
packages listed in the amd64 no-multilib package.mask for example. while |
130 |
these are mostly binary-only, this isnt a binary-specific issue. there are a |
131 |
number of packages which only work on x86/ppc but could easily work in a |
132 |
multilib amd64/ppc64 as a 32bit binary (source code sucks, is heavily asm, |
133 |
something else). |
134 |
|
135 |
> 2. Adding the internal lib32 useflag and usedeps with some workarounds |
136 |
|
137 |
what exactly does this "lib32" do ? naming USE flags according to specific |
138 |
ABI implementations is a bad idea. you have to forget special casing anything |
139 |
to "lib32 vs lib64". amd64, while the most common, is hardly extensible. we |
140 |
must handle multiple ABIs which easily might have the same bitsize. |
141 |
-mike |