[gentoo-dev] Deps on slotted executables (implicit @system tangent)

[gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Michael Orlitzky]

On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:

>> Isn't it possible to disable C++ in GCC with USE="-cxx"?
> 
> It is..  but unfortunately there's no way in DEPEND to ensure it's
> satisfied, as you can have a gcc installed with that flag enabled but
> have a second one (that's actually selected in gcc-config) with it
> disabled.  A pkg_pretend check or a pkg_setup check (if you don't want
> it to just fail in src_configure) is probably the best way to enforce
> that one at this time.  Unless there are other ways I'm not aware of??

Is this a case (as was recently suggested) where we're doing something
stupid rather than asking for help from the PMS? This problem shows up
in a few places -- off the top of my head:

  * GCC (see sys-apps/systemd-217.ebuild)
  * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild)
  * Python (all over the place)
  * Ruby (all over the place)

Since all of the above are slotted, we can DEPEND on them, but we can't
actually be sure that we're using the right slot at build time. The
package manager knows that the right version is there, but it's not at
the moment prepared to find and use it.

Question 1: is it desirable to e.g. switch compilers, compile systemd,
and then switch back? At first I thought the PM should respect my
selected compiler, but after thinking about it for a few minutes, I've
changed my mind. The compiler deps are just like anything else: if I ask
portage to install systemd, it should do what it takes to install
systemd assuming I approve the build plan.

Question2: Is it technically possible to fix this in a new EAPI? I have
no idea.

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

Hi,

On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote:
> On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:
> 
> >> Isn't it possible to disable C++ in GCC with USE="-cxx"?
> > 
> > It is..  but unfortunately there's no way in DEPEND to ensure it's
> > satisfied, as you can have a gcc installed with that flag enabled but
> > have a second one (that's actually selected in gcc-config) with it
> > disabled.  A pkg_pretend check or a pkg_setup check (if you don't want
> > it to just fail in src_configure) is probably the best way to enforce
> > that one at this time.  Unless there are other ways I'm not aware of??
> 
> Is this a case (as was recently suggested) where we're doing something
> stupid rather than asking for help from the PMS? This problem shows up
> in a few places -- off the top of my head:
> 
>   * GCC (see sys-apps/systemd-217.ebuild)
>   * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild)
>   * Python (all over the place)
>   * Ruby (all over the place)
> 
> Since all of the above are slotted, we can DEPEND on them, but we can't
> actually be sure that we're using the right slot at build time. The
> package manager knows that the right version is there, but it's not at
> the moment prepared to find and use it.
> 
> Question 1: is it desirable to e.g. switch compilers, compile systemd,
> and then switch back?

This is definitely a good idea. Some packages are picky about gcc
versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the
latest available gcc version by one.

By the way we have another problem here: packages using cuda
build-time must require the same version of compiler as
nvidia-cuda-toolkit, or build will fail (app-crypt/johntheripper
[cuda] is a good example). Probably cuda eclass should be updated
to reflecth this change as well.

ATM I workaround issue with switching compilers to and from during
emerge run using app-portage/gcc-switcher from stuff overlay.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2292 bytes --]

Dnia 2014-11-14, o godz. 09:08:17
Michael Orlitzky <mjo@gentoo.org> napisał(a):

> On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:
> 
> >> Isn't it possible to disable C++ in GCC with USE="-cxx"?
> > 
> > It is..  but unfortunately there's no way in DEPEND to ensure it's
> > satisfied, as you can have a gcc installed with that flag enabled but
> > have a second one (that's actually selected in gcc-config) with it
> > disabled.  A pkg_pretend check or a pkg_setup check (if you don't want
> > it to just fail in src_configure) is probably the best way to enforce
> > that one at this time.  Unless there are other ways I'm not aware of??
> 
> Is this a case (as was recently suggested) where we're doing something
> stupid rather than asking for help from the PMS? This problem shows up
> in a few places -- off the top of my head:
> 
>   * GCC (see sys-apps/systemd-217.ebuild)
>   * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild)
>   * Python (all over the place)
>   * Ruby (all over the place)
> 
> Since all of the above are slotted, we can DEPEND on them, but we can't
> actually be sure that we're using the right slot at build time. The
> package manager knows that the right version is there, but it's not at
> the moment prepared to find and use it.
> 
> Question 1: is it desirable to e.g. switch compilers, compile systemd,
> and then switch back? At first I thought the PM should respect my
> selected compiler, but after thinking about it for a few minutes, I've
> changed my mind. The compiler deps are just like anything else: if I ask
> portage to install systemd, it should do what it takes to install
> systemd assuming I approve the build plan.

Relying on stuff that can be switched outside the PM scope is always
a bad idea. Think of eselect-opengl -- for a long time, people had to
switch the OpenGL implementation to xorg to build xorg server, and then
back to be able to use anything using OpenGL. Then we fixed xorg-server
to use the underlying headers directly.

I think we should use the same solution for the gcc issues. We already
expect packages to respect CC & CXX -- why not set them then? I'm
keeping my CC & CXX at a specific gcc version for a long time now.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Andreas K. Huettel]

Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko:
> Hi,
> 
> On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote:

> > 
> > Question 1: is it desirable to e.g. switch compilers, compile systemd,
> > and then switch back?
> 
> This is definitely a good idea. Some packages are picky about gcc
> versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the
> latest available gcc version by one.

E.g. cmake may fail to run correctly if it is built with a newer compiler than 
the one currently selected. Or so I remember from a bug some time ago.

This is a recipe for major trouble.


-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 14/11/14 10:50 AM, Andreas K. Huettel wrote:
> Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko:
>> Hi,
>> 
>> On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote:
> 
>>> 
>>> Question 1: is it desirable to e.g. switch compilers, compile
>>> systemd, and then switch back?
>> 
>> This is definitely a good idea. Some packages are picky about
>> gcc versions, e.g. dev-util/nvidia-cuda-toolkit usually lags
>> behind the latest available gcc version by one.
> 
> E.g. cmake may fail to run correctly if it is built with a newer
> compiler than the one currently selected. Or so I remember from a
> bug some time ago.
> 
> This is a recipe for major trouble.
> 
> 

It used to be that after a gcc upgrade people were expected to 'emerge
- -e @world' to make sure everything would work properly by being
rebuilt for the new version.  It's always a possibility that we need
to go back to that type of policy for a particular subset of the tree.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlRmO2IACgkQ2ugaI38ACPBueAD/StqbdxmsPwbDmSgczVGwLThj
mISg96OlEm8TktUONP4A/AnJm0cV7+APPM97YbCg24qC+7Hz4JtSBZnkEUMDghHS
=GfSI
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1257 bytes --]

On Fri, 14 Nov 2014 16:50:24 +0100 Andreas K. Huettel wrote:
> Am Freitag, 14. November 2014, 15:49:17 schrieb Andrew Savchenko:
> > On Fri, 14 Nov 2014 09:08:17 -0500 Michael Orlitzky wrote:
> > > Question 1: is it desirable to e.g. switch compilers, compile systemd,
> > > and then switch back?
> > 
> > This is definitely a good idea. Some packages are picky about gcc
> > versions, e.g. dev-util/nvidia-cuda-toolkit usually lags behind the
> > latest available gcc version by one.
> 
> E.g. cmake may fail to run correctly if it is built with a newer compiler than 
> the one currently selected. Or so I remember from a bug some time ago.

There are packages (or more precisely combinations of packages and
use flags) for which there is no other way to build them. They need
older gcc and they build fine with it.

So the question is whether users will struggle themselves or PMS
will support this in a friendly way.

Please note, I'm not talking about gcc dynamic version switch for
each package in portage. Only small number of them needs this and
if some of this little set will experience gcc-downgrade related
bug (e.g. cmake bug mentioned above), IMHO this should be handled
separately.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Zac Medico]

On 11/14/2014 06:58 AM, Michał Górny wrote:
> Dnia 2014-11-14, o godz. 09:08:17
> Michael Orlitzky <mjo@gentoo.org> napisał(a):
> 
>> On 11/13/2014 10:17 AM, Ian Stakenvicius wrote:
>>
>>>> Isn't it possible to disable C++ in GCC with USE="-cxx"?
>>>
>>> It is..  but unfortunately there's no way in DEPEND to ensure it's
>>> satisfied, as you can have a gcc installed with that flag enabled but
>>> have a second one (that's actually selected in gcc-config) with it
>>> disabled.  A pkg_pretend check or a pkg_setup check (if you don't want
>>> it to just fail in src_configure) is probably the best way to enforce
>>> that one at this time.  Unless there are other ways I'm not aware of??
>>
>> Is this a case (as was recently suggested) where we're doing something
>> stupid rather than asking for help from the PMS? This problem shows up
>> in a few places -- off the top of my head:
>>
>>   * GCC (see sys-apps/systemd-217.ebuild)
>>   * PHP (see comment in app-text/XML-Schema-learner-1.0.0.ebuild)
>>   * Python (all over the place)
>>   * Ruby (all over the place)
>>
>> Since all of the above are slotted, we can DEPEND on them, but we can't
>> actually be sure that we're using the right slot at build time. The
>> package manager knows that the right version is there, but it's not at
>> the moment prepared to find and use it.
>>
>> Question 1: is it desirable to e.g. switch compilers, compile systemd,
>> and then switch back? At first I thought the PM should respect my
>> selected compiler, but after thinking about it for a few minutes, I've
>> changed my mind. The compiler deps are just like anything else: if I ask
>> portage to install systemd, it should do what it takes to install
>> systemd assuming I approve the build plan.
> 
> Relying on stuff that can be switched outside the PM scope is always
> a bad idea. Think of eselect-opengl -- for a long time, people had to
> switch the OpenGL implementation to xorg to build xorg server, and then
> back to be able to use anything using OpenGL. Then we fixed xorg-server
> to use the underlying headers directly.

Yeah, having ebuilds switch the global compiler configuration would be
completely insane. If they need to select a different local compiler via
a mechanism like CC and CXX, as you suggest below, then that's fine.

> I think we should use the same solution for the gcc issues. We already
> expect packages to respect CC & CXX -- why not set them then? I'm
> keeping my CC & CXX at a specific gcc version for a long time now.
> 


-- 
Thanks,
Zac

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Fri, 14 Nov 2014 09:08:17 -0500
Michael Orlitzky <mjo@gentoo.org> wrote:
> Question 1: is it desirable to e.g. switch compilers, compile systemd,
> and then switch back?

This will horrifically break things like Portage's parallel build...

Note that on every distribution except Gentoo, there are no problems
with running multiple versions of gcc simultaneously.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Rich Freeman]

On Fri, Nov 14, 2014 at 1:22 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Fri, 14 Nov 2014 09:08:17 -0500
> Michael Orlitzky <mjo@gentoo.org> wrote:
>> Question 1: is it desirable to e.g. switch compilers, compile systemd,
>> and then switch back?
>
> This will horrifically break things like Portage's parallel build...
>
> Note that on every distribution except Gentoo, there are no problems
> with running multiple versions of gcc simultaneously.
>

Not really an apples to apples.  If you exclusively use binary
packages I suspect that you won't run into any of these problems on
Gentoo either.

However, the right way to do this isn't to toggle some global setting
- it is to just apply specific settings when building specific
packages.

--
Rich

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

On Fri, 14 Nov 2014 14:17:12 -0500
Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Nov 14, 2014 at 1:22 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Fri, 14 Nov 2014 09:08:17 -0500
> > Michael Orlitzky <mjo@gentoo.org> wrote:
> >> Question 1: is it desirable to e.g. switch compilers, compile
> >> systemd, and then switch back?
> >
> > This will horrifically break things like Portage's parallel build...
> >
> > Note that on every distribution except Gentoo, there are no problems
> > with running multiple versions of gcc simultaneously.
> >
> 
> Not really an apples to apples.  If you exclusively use binary
> packages I suspect that you won't run into any of these problems on
> Gentoo either.

It *also* isn't an issue on any other source based distribution. This
is entirely down to Gentoo libstdc++ silliness.

> However, the right way to do this isn't to toggle some global setting
> - it is to just apply specific settings when building specific
> packages.

Which doesn't work properly on Gentoo due to the weird way libstdc++ is
handled.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Deps on slotted executables (implicit @system tangent)

[Pacho Ramos]

El vie, 14-11-2014 a las 19:23 +0000, Ciaran McCreesh escribió:
[...]
> It *also* isn't an issue on any other source based distribution. This
> is entirely down to Gentoo libstdc++ silliness.
> 
> > However, the right way to do this isn't to toggle some global setting
> > - it is to just apply specific settings when building specific
> > packages.
> 
> Which doesn't work properly on Gentoo due to the weird way libstdc++ is
> handled.
> 

Not sure if you could point to some link or bug... or a longer
explanation about that "silliness" for people like me that are not aware
of that problem. Thanks :)