Hi, well i want request a eselect package for GCC, this is because when we test things or similar, some times we need other versions of GCC, but if we upgrade or downgrade to unstable versions the system can be a mess, so the idea is can enable a system gcc (ex to portage), and a user gcc to do all experiments/configs we need. Thx. Cya.
Why is this assigned to SELinux?
You can always use a specific version of gcc by calling it out explicitly: gcc-5.4.0 ........ Does that fit your need?
Hi, its an option, but its only the hald of the solution, to gcc-5.4 can works properly its necessary edit the user envs, libs and all that things. The next, point, when the user uses this type of tools are normally to use as default user env, so start changing all of this for every terminal i think don't is a good idea, and if we edit the user env directly that can affect portage. For now i'm using gcc-config 2 //gcc+5.4 . /etc/profile to work, but in that time i can't use portage or similar, when i do it the gcc-config change to gcc-4.9 but user env continues with gcc-5.4 and basically is a mess (and i don't wanna try this again). So i think the right way to do this is in eselect with a system and user option, like in java-vm. Its possible change the SELinux description from the bug report page? (https://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux) Report issues with SELinux policies, support and tools here to Report issues with SELinux: policies, support and tools here i know its a detail, but you know. Thx. Cya.
(In reply to Lagu from comment #3) > to work, but in that time i can't use portage or similar, when i do it the > gcc-config change to gcc-4.9 but user env continues with gcc-5.4 and > basically is a mess (and i don't wanna try this again). > > So i think the right way to do this is in eselect with a system and user > option, like in java-vm. It seems that you can prepend PATH with $HOME/bin and make a symlink of $HOME/bin/gcc to /usr/bin/gcc-4.9.4 to achieve what you want. Or if your build system support it, just export CC=gcc-4.9.4 and it's done. I still don't see the necessity of a fancy eselect.
Hi, in first place i don't know what exactly need GCC to works properly, for now the only i know is it need match the PATH, MANPATH and INFOPATH directories of GCC with the version, now if i change CC, only change the C++ compiler not all GCC compilers, and only in one terminal not in the user env, we can change it in some way but sadly not all methods like .profile works in terminals, in someone works and in others not. (think this should works in tty too). So, this is very... ugly, i think this can be one of the reasons of why exist java-vm in eselect. Thx. Cya.
(In reply to Lagu from comment #5) > Hi, in first place i don't know what exactly need GCC to works properly, for > now the only i know is it need match the PATH, MANPATH and INFOPATH > irectories of GCC with the version, Why do MANPATH and INFOPATH matter if you want to call a certain version of gcc? > now if i change CC, only change the C++ > compiler not all GCC compilers, and only in one terminal not in the user > env, we can change it in some way but sadly not all methods like .profile > works in terminals, in someone works and in others not. (think this should > works in tty too). > > So, this is very... ugly, i think this can be one of the reasons of why > exist java-vm in eselect. Thanks. I understand your need. You can have a look into /usr/bin/gcc-config and /usr/share/eselect/modules/java-vm.eselect to see if such a feature could be ported to gcc-config.
Hi, thx, i'll take look on it, i check part of java-vm until now i can't found the right way to do this, about the other env vars, MANPATH and INFOPATH have part of the info of gcc, its only because if i'm using GCC-5.4 and i call "man g++" need get the 5.4 of g++, so if we don't update that vars with GCC 5.4 we will get the GCC-4.9 documentation. echo $MANPATH /home/pipe/.gentoo/java-config-2/current-user-vm/man:/usr/local/share/man:/usr/share/man:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/man:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.25.1/man:/etc/java-config-2/current-system-vm/man/:/usr/lib64/php5.6/man/:/usr/share/postgresql/man/:/usr/share/postgresql-9.5/man/ echo $INFOPATH /usr/share/info:/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.3/info:/usr/share/binutils-data/x86_64-pc-linux-gnu/2.25.1/info
only for the record, files of GCC in PATH var: echo $PATH /usr/local/bin:/usr/bin:/bin:/opt/bin:/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3:/opt/android-sdk-update-manager/tools:/opt/android-sdk-update-manager/platform-tools:/opt/nvidia-cg-toolkit/bin:/usr/games/bin:/opt/cuda/bin:/home/pipe/.local/bin:/home/pipe/.local/pspdev/bin
what you describe is already possible and host nothing to do with eselect: eval "$(gcc-config -E 5.4.0)" ... do whatever you want with gcc-5.4.0 ...
Hi, i already wrote here we can do that, but the problem is when we run something like portage the user env is a mess, so don't is a valid option.
(In reply to Lagu from comment #10) if your env is broken, then i really don't see what you expect eselect to do for you. eselect manages a global resource exactly like gcc-config does today. if you want per-user settings, you can already do that now. you need to concretely describe what it is you're trying to do.
Hi, my intentions are really specific, basically split the build env for the system and the user because actually is mixed, is ideal can choose what versions of GCC we can use both envs in a independent way. As i wrote we can't use gcc-config to set the user env build, because when we run portage it set back some configs to compile with some version, a point here is i really don't know how portage choose the gcc version(maybe choose the lower version in slots), if i choose 5.4 i normally can think it'll use it but don't is the case. The user env only is affected for this behavior and for that reason is a mess, even, we can set 5.4, run portage, it set some configs back to 4.9, then i set again 5.4 in the middle of portage to can use it, and now we have really mess. So, in summary: Users and System env should be split Users should be able to can choose their GCC versions to use in build envs Well this idea don't is too crazy, one of the idea of gentoo is can set the control of the system to the user, so can choose this type of things i think should be natural. An important point, as you know normally higher versions of apps like GCC have a lot of problems, for a lot of reasons, so if you fix the behavior and merge system and user build env in the right way, its very probable we not always want compile the system with a higher version, saying in a safe way, compile the system with a safer GCC version and can use other GCC version to can compile from the user env, for example when we need "GCC >= 5" or we want test a new feature of GCC, and we don't always want install apps in the system, i we are testing and experimenting its a bad idea, and i think its normal avoid it, so the pre-step for that is compile and test from the user env. I can continue arguing (in a positive way) about this, but i think the reasons can be very similar of why in eselect exist java-vm with the user and system options. Thx. Cya.
(In reply to Lagu from comment #12) sorry, but i'm not seeing why the current `gcc-config -E` behavior doesn't already do what you need it to. gcc settings are taken from the environment. they aren't loaded from a central repository in like /etc. the -E flag gives you an environment for a specific version. so if you want one user to run gcc-4.9.0, then run gcc-config in their bashrc or something. if you want a diff user to run 5.2.0, then do the same thing. gcc-config's design is specifically meant to only leverage the environment (e.g. the $PATH). resorting to looking up settings in a database is a non-goal.
mm, i think this issue is little more things than only choose gcc-version, lets try other rute to approach this: How can i set one version (or pattern) of GCC to use in portage? How can i set a different version of GCC to use in the user env? Extra question How can i build with Portage and in the user env at the same time? Note: Sadly the gcc-config don't affect portage env, but portage affect the user env, so don't is exactly non-globlal, do the test, choose other gcc version in the user env, run portage, and magically the gcc of user env change. Note 2: I try this with two different slots of GCC, 4.9 and 5.4 Thx. Cya.
how you want to manage the active set of env vars at any time is up to you and is trivial to do eval "$(gcc-config -E 456)" (eval "$(gcc-config -E 123)"; emerge ...) if the only thing you care about is compiling with gcc vers, then you could also just simply set CC/CXX in your make.conf to point to the right value: CC="gcc-4.9.4" CXX="g++-4.9.4" then it doesn't matter what the active env is set up for because portage is pinned to those values.
Hi!, thx for the solution, now sadly the part of the problem persist, if we do that we will unable to compile from the user env while portage is running.... or we run again gcc-config and break portage. And change CC or CX don't is the same as use gcc-config, that values don't change $PATH, and only change two compilers, GCC have more than that, and gcc-config requieres reload libs to works properly. Other point is if we do that we will need start updating with every GCC version the vars..., i think do that with USEs is a lot, start adding new vars when can be handled in a easy way can be better. And sadly gcc-config don't works with portage, when we run portage it change the config to default.
(In reply to Lagu from comment #16) all the gcc programs should have versioned suffixes, so you can set the right vars to them (e.g. FC=gfortran-4.9.2). not that that scales well. there is no problem with library paths. the gcc binary itself takes care of that. i'm still not seeing a problem here. gcc-config, run as root & w/out -E, selects the default version for everyone. if you want to override it, run `gcc-config -E xxx` before you do whatever it is you want to do. if you run `gcc-config -E` and then `emerge`, then emerge using that version instead of the default one selected for the overall system is completely WAI.
mm, i still don't like set manually all compilers names......... Well, a little question, is possible do portage don't change the build env?, basically do it works with their own version while we can use the one we want.
(In reply to Lagu from comment #18) > mm, i still don't like set manually all compilers names......... You can put eval $(gcc-config -E 456) into your user .profile.
Hi Mike, (In reply to SpanKY from comment #15) > (eval "$(gcc-config -E 123)"; emerge ...) I don't think this works. emerge overrides PATH. It will still use the default version of gcc even with gcc-config -E env setup.
Hi, sadly .profile don't works fine in all tty emulators, and, even i found a lot of problems in for example gnome-terminal, part of the idea is this can works in tty too.
Hi!, i found other problem D: A little of history of this - I was using gcc-4.9 along in portage (no problem), then i install in a new slot the 5.4 version (here mentioned problem) but the nice part is portage still use 4.9 so no problem, but with a update portage upgrade 4.9 to 4.9.3 or something similar, basically it need reinstall the 4.9 slot and here the appears a new problem, when this installation was complete portage start using the 5.4 version of gcc...., and obvs now i can't upgrade, broken packages and time real links... And i can't fix broken libs with revdep-rebuild for this bug https://bugs.gentoo.org/show_bug.cgi?id=578766... So i still think we need a eselect-gcc package to can handle the gcc versions. You recommend use a make.conf var to do this, but for any upgrade in gcc and all the others packages will fail because portage will can't found the previous gcc... When the package versions are handled via eselect normally are upgraded in the moment like icedtea, so i think is more easy handle this in this way, obvs if exist a better way i have no problem with that. Thx. Cya.
