Mike Frysinger schrieb: > > another quick look at _setup_abi_env() looks like it needs work: > - LD should not default to `ld`
Whats your suggestion? > - the -L paths to system dirs in LDFLAGS should not be there -- the > toolchain > can handle these just fine Last time i tried without, some packages failed to compile, will test it again to check, if its still needed > - missing CPPFLAGS handling Added > - see previous comments re-pkg-config Will have a look the next days > - you dont declare pyver local fixed > - the abi if check is uncommon syntax. "! [[ a == b ]]" -> "[[ a != b ]]" fixed > how do you control whether the multilib headers are needed ? it'll probably > make sense in general, but there are def some packages where this will only > get in the way (the toolchain ones). What do you mean here? If the diff between ABIs makes sense to install seperate versions? > how do you differentiate between packages where multi ABIs make no sense ? > for example, most packages that dont install any libraries but just binaries. > > let's use the simple package app-text/tree. I dont differentiate. Currently i build for every ABI, if lib32 useflag is set and multilib useflag is not set. The idea behind it is to allow the installation of additional 32bit binaries, if requested. > a lot of this multilib code should probably continue to live in the tree as > it's a pretty big base of code to formalize that could do with fixes over > time. i.e. we figure out that certain paths / define protections dont work > so > well, so changing them to something else would require PMS changing !? there > has been talk before about pushing a lot of basic stuff to the tree so things > dont have to be encoded in the PMS. How do you want to do this? Require package managers to inherit some file/eclass? > how are packages handled that can only be used via 1 ABI ? any of the > packages listed in the amd64 no-multilib package.mask for example. while > these are mostly binary-only, this isnt a binary-specific issue. there are a > number of packages which only work on x86/ppc but could easily work in a > multilib amd64/ppc64 as a 32bit binary (source code sucks, is heavily asm, > something else). The binary-only ones are easy. Since they dont interact with the env, they can be installed as usual. If they depend on a new enough package manager with multilib support, they could also depend on the useflag for the additional 32bit libs they need. > >> 2. Adding the internal lib32 useflag and usedeps with some workarounds > > what exactly does this "lib32" do ? naming USE flags according to specific > ABI implementations is a bad idea. you have to forget special casing > anything > to "lib32 vs lib64". amd64, while the most common, is hardly extensible. we > must handle multiple ABIs which easily might have the same bitsize. "lib32" is added to IUSE, you can enable as as every other useflag. Internally, portage does add [lib32?] usedeps to all dependencies. So if you enable the lib32 useflag, portage will require this useflag for all dependencies too. I dont mind renaming it, if there is some other sane naming for it. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
