Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Matt Turner schrieb: I think this is doable, and I think I have a good reason for wanting to be able to do it. I have no idea why Tommy[D] or AxS want to do it. I've never discussed my plans with them. The main reason seems indeed being able to build 32 bit software where a 32 bit toolchain would run into address space limitations. Those who suffer most currently are browser folks, who resorted to some tricks and workarounds[1] to stay afloat a little longer. FWIW, the problem is not limited to Linux[2]. Best regards, Chí-Thanh Christopher Nguyễn [1] https://bugs.gentoo.org/show_bug.cgi?id=471810 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=709193
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:28 PM, Matt Turner wrote: On Fri, Aug 9, 2013 at 10:52 AM, Michał Górny mgo...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? Nope. That would require every package to be multilib. The amount of work exceeds the benefit from it. If you really want to play like this, you are either looking for multilib-portage or some hackery in make.conf. I don't see why that would be. I think it would require some profile support, but that's simple. For instance on mips I'd like to be able to build the toolchain as 64-bit binaries (tracked in bug 477956) as to avoid the small virtual memory limit of the 32-bit ABIs. The rest of the system I want to remain ABI_MIPS=n32. As far as I can tell the things that would need to be built for N64 would be: sys-libs/zlib : DONE as of 1.2.8-r1 dev-libs/mpfr : Not done (EAPI=3) dev-libs/gmp : Not done (EAPI=0) (part of baselibs) dev-libs/mpc : Not done (EAPI=0) sys-devel/gettext : Not done (EAPI=2) (part of baselibs) dev-libs/cloog-ppl: Not done (EAPI=4) dev-libs/isl : Not done (EAPI=4) Under a multilib profile, gcc's libraries are built for each ABI. Same for glibc. I think this is doable, and I think I have a good reason for wanting to be able to do it. I have no idea why Tommy[D] or AxS want to do it. I've never discussed my plans with them. I personally don't want to do it; but I also don't want to block the possibility for others to do it, too. That aside... For your example above, all you need are some 'n64' bits on an 'n32' system, and it looks like what you need from that list are the libraries, correct? Do you need n64 binaries as well for those packages, or would it be fine for the bins to be left out for n64? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIGOO4ACgkQ2ugaI38ACPAxIQEAqPira7yfhtbLb1qdbawNh/Fj b6zU+V/5qNZS1kadWjMA/3wPeX2Lz2Av2JsM5Q6Cpsk0xoC94LPPiNk/F9qMeH0D =LK/c -END PGP SIGNATURE-
[gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:43 AM, Michał Górny wrote: Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. I don't think there was anything authoritative about Tommy's post? 'Please' is generally a request, isn't it? I asked Tommy to post this, because I had the impression that this method (only building libs for non-native_abi) is the perfectly acceptable and proper way to move forward with multilib-build.eclass conversion -- and I figured other dev's might too, as more and more get involved with converting their lib-providing ebuilds to multilib-build et. al.. I assume bugs are still getting filed for proper case-by-case reporting and fixing... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFDzcACgkQ2ugaI38ACPBsDQD/eV2lbT8t7OvZTQYHyH9RePaa 18c8bnMwKKygcPweBpUA/RwrDKA+nakrF98acE+D8olv0Od9f+f4Vs/Xk06hB4D4 =sknn -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases - fill bugs and patches for ebuilds disabling it by other means (there are because this function didnt exit at the beginning) no, we won't be building useless stuff to throw it away one minute later, thanks for the bloat.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-08-09, o godz. 11:48:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:43 AM, Michał Górny wrote: Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. I don't think there was anything authoritative about Tommy's post? 'Please' is generally a request, isn't it? It is a request given by a person not involved with the multilib work and a request that is exactly the opposite of what we're doing and recommending so far. Plus it's against QA. I asked Tommy to post this, because I had the impression that this method (only building libs for non-native_abi) is the perfectly acceptable and proper way to move forward with multilib-build.eclass conversion -- and I figured other dev's might too, as more and more get involved with converting their lib-providing ebuilds to multilib-build et. al.. And it is the best method. We're not going to regress into multilib-portage. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJSBRQlXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKeLAQAJVQnbcDJm/3uafYW3obUhth b9AyXt20fR6IcG0m0oSQUAtIRaKcuT7LPSR1SVlRVnnKRhNkC5BGk2Q6CgbsOuX/ 37Yr6UPZkE+U+JInrveF+hyHlFX2NiQHi+J6X/A6y17HWyT284qlkI8yVIdJrbPW nsEC4rKp6GKxnY3oIDKdB3aqD4vAnOjh0lG0VbWi0Q2QMYeMDzyuWFn3b9W50kfu 2VarJjv7PClABwRHmWXBZzoRF16ZUieQGidx+kzpbVDah5LC5eccdYHaDSt3YALT 4HdmCOZZ0UVGEnOFqCIYNB/fIhZZdkllY/oCQmmqgaeVozsGaRt9qq3ho6MDdyWB pjByQpwqb45Pi4aMh9QKSoKCfSc/P7ZfuSPQJmxVZcM2Y5M5nSaP7Yjg2FHXOWkb m+uLVkAud0Wl12Og0+iTpWELdY0DITP9dv4JajDy3ggLy5RIOpfgtOA6vTHXiXB/ /XUom36g55k0MziOsNX/SnpHOLiHeEnLAMQKLcf/28BMG+wyTasbQMfeYwVuB0OA bJeoHm2JVdD+S/7X80kHLDJyr3eyNj8urLt87Z33Jduux/BOWxIEyGSzCLWjZHsU tVzzuL0O9Vg4Hi1qCqS0+KX4rmnAPEP7EaAAZR/5CjPZy2SpAWGCOPz5jR5cPxsX sYUYYE/vgNRMKsEPKycq =lcuM -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 9 Aug 2013 12:02:10 -0400 Alexis Ballier aball...@gentoo.org wrote: no, we won't be building useless stuff to throw it away one minute later, thanks for the bloat. and i'm not even talking about the fact that this wont work unless you introduce bloated deps by requiring unneeded multilib deps
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? - fill bugs and patches for ebuilds disabling it by other means (there are because this function didnt exit at the beginning) see above no, we won't be building useless stuff to throw it away one minute later, thanks for the bloat. We already do it in many cases, just take complete package rebuilds due to USE flag changes. Having some more lines compiled wont kill your computer, but will allow people to use their own target setup. If you really care about building something, you should know, that Gentoo is not the right place to complain about. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Michał Górny schrieb: Dnia 2013-08-09, o godz. 11:48:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:43 AM, Michał Górny wrote: Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. I don't think there was anything authoritative about Tommy's post? 'Please' is generally a request, isn't it? It is a request given by a person not involved with the multilib work and a request that is exactly the opposite of what we're doing and recommending so far. Plus it's against QA. I did work on multilib long before you even tried to think about it more then just i dont want, what he offers. So please stop your lies. And we are who? Please dont mix yourself with a group, thanks And bulding binaries for other ABIs should be against QA? Please show me that policy it violates. I asked Tommy to post this, because I had the impression that this method (only building libs for non-native_abi) is the perfectly acceptable and proper way to move forward with multilib-build.eclass conversion -- and I figured other dev's might too, as more and more get involved with converting their lib-providing ebuilds to multilib-build et. al.. And it is the best method. We're not going to regress into multilib-portage. I did not write any line about multilib-portage, so really stop putting words into my mouth i never said. Also stop assigning everything i say to multilib-portage. And stop writing in every post, how you hate/dislike/are against multilib-portage. When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 and you might notice, that even with a default portage (just a reminder, no multilib in that word, just in case you missed it) you will get no binaries. And this is exactly, what i said: A user with 32bit userland target on a system with 64bit toolchain will not get any binaries. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 12:09 PM, Michał Górny wrote: Dnia 2013-08-09, o godz. 11:48:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:43 AM, Michał Górny wrote: Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. I don't think there was anything authoritative about Tommy's post? 'Please' is generally a request, isn't it? It is a request given by a person not involved with the multilib work and a request that is exactly the opposite of what we're doing and recommending so far. Plus it's against QA. I asked Tommy to post this, because I had the impression that this method (only building libs for non-native_abi) is the perfectly acceptable and proper way to move forward with multilib-build.eclass conversion -- and I figured other dev's might too, as more and more get involved with converting their lib-providing ebuilds to multilib-build et. al.. And it is the best method. We're not going to regress into multilib-portage. ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFHZEACgkQ2ugaI38ACPA0ggEAhTBHdr0H9N6vkbWzpkQOKbF9 yrKGlCsryxs41nQnPfoBAJe4QXtr9cqjaT9C7EO/lYkX1m49uhNdyg2yzhe1iDlq =I4UD -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 18:32:04 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? native abi = the abi you want the binaries for and the one you always build your libs with... [...] no, we won't be building useless stuff to throw it away one minute later, thanks for the bloat. We already do it in many cases, just take complete package rebuilds due to USE flag changes. Feel free to propose improvements to this, but it is unrelated I'm afraid. Let's emerge -e world after each sync just because we can :)
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 12:49:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? there is a solution to this, it's just not the one tommy suggests.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:09 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. well, it does -- it's very easy to see just by testing it. And portage not allowing this doesn't make sense to me because if it did then we wouldn't have the ability to test what the build output is going to be for any one particular ABI_X86 value so I would _really_ hope that this bug doesn't get fixed. of course, all of the above is independent from expecting/supporting a user to set it in make.conf -- about that please see my other post -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFI18ACgkQ2ugaI38ACPCBxAEAoK7U9l9ZRCD/ctsS0yyy1i6K zGhtHo8bKDofLTqryAQA/3q8VQW0AJKrDvpqXo/BowhDb6cVz02E6P+t1CRsITYh =dgb/ -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:06 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 12:49:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? there is a solution to this, it's just not the one tommy suggests. ...so #1, what is it, and #2, why isn't the one tommy suggests a possibility? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFI3oACgkQ2ugaI38ACPDBvAD/Spy95gjE6tZb24gcDQWyjk7o IkNlzEPJfFHDLeJRWaAA/1KMN9uwStVJv19xWHZiQHBQ7Z41/a0smcR1k2Wz8yCt =Di37 -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 13:14:34 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:06 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 12:49:21 -0400 Ian Stakenvicius a...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? there is a solution to this, it's just not the one tommy suggests. ...so #1, what is it, and #2, why isn't the one tommy suggests a possibility? see my first reply to the thread
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Alexis Ballier schrieb: On Fri, 09 Aug 2013 18:32:04 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? native abi = the abi you want the binaries for and the one you always build your libs with... so tell me the native abi for this case: toolchain=64bit, userland=32bit from your line: the abi you wan the binaries for: x86 the one you always build your libs with: amd64 native abi = x86 = amd64? [...] no, we won't be building useless stuff to throw it away one minute later, thanks for the bloat. We already do it in many cases, just take complete package rebuilds due to USE flag changes. Feel free to propose improvements to this, but it is unrelated I'm afraid. Let's emerge -e world after each sync just because we can :) dont miss some emerge -e world run after any package has been (re)built) ;) -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 13:14:07 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:09 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. well, it does -- it's very easy to see just by testing it. And portage not allowing this doesn't make sense to me because if it did then we wouldn't have the ability to test what the build output is going to be for any one particular ABI_X86 value so I would _really_ hope that this bug doesn't get fixed. I don't get it. We're talking about multi_lib_ not multi arch. There is one ABI you build everything for (what you had before multilib eclasses) and the other ABIs for which you build extra libraries. If you disable building for your default abi then it's quite normal you don't get anything, but this shouldn't be allowed for obvious reasons.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 19:23:50 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 18:32:04 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? native abi = the abi you want the binaries for and the one you always build your libs with... so tell me the native abi for this case: toolchain=64bit, userland=32bit from your line: the abi you wan the binaries for: x86 the one you always build your libs with: amd64 native abi = x86 = amd64? First of all, toolchain is part of userland For this case maybe the DEFAULT_ABI variable is a bit abused atm. This can be solved by adding NATIVE_ABI=$DEFAULT_ABI to the profiles and changing multilib_is_native_abi to ABI == NATIVE_ABI.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:28 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 13:14:07 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:09 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. well, it does -- it's very easy to see just by testing it. And portage not allowing this doesn't make sense to me because if it did then we wouldn't have the ability to test what the build output is going to be for any one particular ABI_X86 value so I would _really_ hope that this bug doesn't get fixed. I don't get it. We're talking about multi_lib_ not multi arch. There is one ABI you build everything for (what you had before multilib eclasses) and the other ABIs for which you build extra libraries. I guess I should have done a sed 's/emerge --oneshot (.*)$/ebuild install \1/' on that commandline. My point was, I'd be upset if portage suddenly rejected and forced my native_abi value all the time if i'm trying to explicitly test a certain build output. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFKJ8ACgkQ2ugaI38ACPBfkQD9Gr+CYWcF0kJadUHWUqV8arao XDTw1QPmCbWsqWNb5QQBAJp7veuM3eV/xS8EfnVD8gq8vIKfUDBFt9AuF/vAS0wA =yBNO -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 13:36:31 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:28 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 13:14:07 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:09 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. well, it does -- it's very easy to see just by testing it. And portage not allowing this doesn't make sense to me because if it did then we wouldn't have the ability to test what the build output is going to be for any one particular ABI_X86 value so I would _really_ hope that this bug doesn't get fixed. I don't get it. We're talking about multi_lib_ not multi arch. There is one ABI you build everything for (what you had before multilib eclasses) and the other ABIs for which you build extra libraries. I guess I should have done a sed 's/emerge --oneshot (.*)$/ebuild install \1/' on that commandline. My point was, I'd be upset if portage suddenly rejected and forced my native_abi value all the time if i'm trying to explicitly test a certain build output. You're free to mess with your profiles. You're free to override important variables in make.conf. You're free to break your system. For an example I've seen recently, see e.g. bug #479414 How did you test x86 binaries on amd64 before ? With a chroot. This has not changed.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Dnia 2013-08-09, o godz. 13:09:57 Alexis Ballier aball...@gentoo.org napisał(a): On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. Just to be clear, the main reason for forcing default ABI is that you it guarantees sane dependencies. That is, if you do a regular dep on multilib package from non-multilib package: RDEPEND=x11-libs/libX11 you expect that dep to pull in the lib for native ABI. If that wasn't enforced, we'd have to use proper USE-deps in every package in the tree. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dnia 2013-08-09, o godz. 12:49:21 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 12:09 PM, Michał Górny wrote: Dnia 2013-08-09, o godz. 11:48:07 Ian Stakenvicius a...@gentoo.org napisał(a): -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 11:43 AM, Michał Górny wrote: Dnia 2013-08-09, o godz. 17:32:56 Thomas Sachau to...@gentoo.org napisał(a): As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. Then it is a bug that needs to be reported and fixed properly. And you should report it properly, to the proper people rather than stating authoritatively that a silly work-around is a proper solution. I don't think there was anything authoritative about Tommy's post? 'Please' is generally a request, isn't it? It is a request given by a person not involved with the multilib work and a request that is exactly the opposite of what we're doing and recommending so far. Plus it's against QA. I asked Tommy to post this, because I had the impression that this method (only building libs for non-native_abi) is the perfectly acceptable and proper way to move forward with multilib-build.eclass conversion -- and I figured other dev's might too, as more and more get involved with converting their lib-providing ebuilds to multilib-build et. al.. And it is the best method. We're not going to regress into multilib-portage. ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? Nope. That would require every package to be multilib. The amount of work exceeds the benefit from it. If you really want to play like this, you are either looking for multilib-portage or some hackery in make.conf. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iQJ8BAEBCgBmBQJSBSxbXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ1RUJGMjBGOTk2RkIzQzIyQ0M2RkNBNDBC QUJGMUQ1RkY4QzgxMTBBAAoJELq/HV/4yBEKKSoQAIVD0xbGdPdrfLYGTpJWWhOC D8qqPakxtiYFCAX83Go/IQ95Cad0FCvgKnaHaddP5VSvb5z35gd4aPRI1fPjgvVl 8g103kEUDTov3YlIRxRpnC8+65G4fsdqbUgYsNcT4IGapal2sVlgjzNxRy6rWIAT v713IJOYuTiwMzsUSGDXxDWyKlQKOS/KMazMxGJgfVuJgr+6LLO4nNllVAgnkwdJ LsbWfewKFHsq6EHtU3MBl7EffQSMyAG0iKwlAqGooxCC+vJW0mD27/IflN/FDtks 9nuy0nBDdCp6Wa+ON7kCd8huYK7sy9MR7fxsunXZmzUZJqLbfOfBTk0F2/8i7df9 sobbQRizCR2t1yOiT3JmbwqykWxRGxrbqXvJqy22jczaO5/hF8JUG//ZeZnDYb95 3YC8XsmavuwLFuEWm+363K7IOeLNs8MbYulre4nJGz7aIgWlDVynpdZX4r9c1dIU ra755ovt5eOxC92rB7UqiyOUU72Ofnd1xy4PrQsHC1gXwgWvLtDIGc3qjZ6ZN74H q7TMGpupNHRgfO4motnDRULwqS/WQKBiZoliSYNGA0NZz9VeTxa139cKk7ivCjYP g3khoo6w7Ro+aAwlnrXThGKpNFujenY7kSkkWDwNUut65BleY/Edb6PVfsPpoaa3 Yq2jKUSBKrFMmP42JhiQ =C422 -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 9 Aug 2013 19:54:01 +0200 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-08-09, o godz. 19:23:50 Thomas Sachau to...@gentoo.org napisał(a): Alexis Ballier schrieb: On Fri, 09 Aug 2013 18:32:04 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? native abi = the abi you want the binaries for and the one you always build your libs with... so tell me the native abi for this case: toolchain=64bit, userland=32bit Excuse me, but where does such configuration occur? I don't think Gentoo is providing stages like this. I think he's referring to mips team efforts to get a 64bits gcc (to lift the memory limit for debug builds of some c++ packages) but wanting to keep a ~x32 userland.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
Dnia 2013-08-09, o godz. 19:23:50 Thomas Sachau to...@gentoo.org napisał(a): Alexis Ballier schrieb: On Fri, 09 Aug 2013 18:32:04 +0200 Thomas Sachau to...@gentoo.org wrote: Alexis Ballier schrieb: On Fri, 09 Aug 2013 17:32:56 +0200 Thomas Sachau to...@gentoo.org wrote: As the topic says, when someone converts an ebuild to multilib, please dont disable binary building for other ABIs, as has already been done for some packages. This will break e.g. for users who target 64bit toolchain and 32bit userland, since those would not get any binaries from building for none-default ABIs. - submit a patch against multilib_is_native_abi for those corner cases huh? Please tell me, how a changed multilib_is_native_abi function would help here. Either you restrict something to native abi or you dont, having a check telling you true - we are either native abi or not is not really usefull, is it? native abi = the abi you want the binaries for and the one you always build your libs with... so tell me the native abi for this case: toolchain=64bit, userland=32bit Excuse me, but where does such configuration occur? I don't think Gentoo is providing stages like this. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:41 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 13:36:31 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:28 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 13:14:07 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/08/13 01:09 PM, Alexis Ballier wrote: On Fri, 09 Aug 2013 18:41:59 +0200 Thomas Sachau to...@gentoo.org wrote: When when you have done it, try e.g. this: ABI_X86=32 emerge --oneshot =libjpeg-turbo-1.3.0-r2 that's why default abi is in use.force; if this is allowed and really disables abi_x86_64 on a stock amd64 profile I'd consider this a portage bug. well, it does -- it's very easy to see just by testing it. And portage not allowing this doesn't make sense to me because if it did then we wouldn't have the ability to test what the build output is going to be for any one particular ABI_X86 value so I would _really_ hope that this bug doesn't get fixed. I don't get it. We're talking about multi_lib_ not multi arch. There is one ABI you build everything for (what you had before multilib eclasses) and the other ABIs for which you build extra libraries. I guess I should have done a sed 's/emerge --oneshot (.*)$/ebuild install \1/' on that commandline. My point was, I'd be upset if portage suddenly rejected and forced my native_abi value all the time if i'm trying to explicitly test a certain build output. You're free to mess with your profiles. You're free to override important variables in make.conf. You're free to break your system. For an example I've seen recently, see e.g. bug #479414 How did you test x86 binaries on amd64 before ? With a chroot. This has not changed. I don't want to test the binaries, I want to test the build/install process. But this sub-thread is neither here nor there to the main issue. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIFMnUACgkQ2ugaI38ACPAxeQEAtLAjadX1VxEfyWJRp6hZToTT ac3P/rLYxS25h80KeHQA/i1ggFCYls9fR/bHnLuu57JICxsV5qeH1oQaJcKS564w =4hiW -END PGP SIGNATURE-
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, 09 Aug 2013 14:18:29 -0400 Ian Stakenvicius a...@gentoo.org wrote: I don't want to test the binaries, I want to test the build/install process. But this sub-thread is neither here nor there to the main issue. Then there is no point in testing an invalid process consisting of disabling your default abi :)
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, Aug 9, 2013 at 10:52 AM, Michał Górny mgo...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? Nope. That would require every package to be multilib. The amount of work exceeds the benefit from it. If you really want to play like this, you are either looking for multilib-portage or some hackery in make.conf. I don't see why that would be. I think it would require some profile support, but that's simple. For instance on mips I'd like to be able to build the toolchain as 64-bit binaries (tracked in bug 477956) as to avoid the small virtual memory limit of the 32-bit ABIs. The rest of the system I want to remain ABI_MIPS=n32. As far as I can tell the things that would need to be built for N64 would be: sys-libs/zlib : DONE as of 1.2.8-r1 dev-libs/mpfr : Not done (EAPI=3) dev-libs/gmp : Not done (EAPI=0) (part of baselibs) dev-libs/mpc : Not done (EAPI=0) sys-devel/gettext : Not done (EAPI=2) (part of baselibs) dev-libs/cloog-ppl: Not done (EAPI=4) dev-libs/isl : Not done (EAPI=4) Under a multilib profile, gcc's libraries are built for each ABI. Same for glibc. I think this is doable, and I think I have a good reason for wanting to be able to do it. I have no idea why Tommy[D] or AxS want to do it. I've never discussed my plans with them.
