| 1 |
On Tue, 29 Dec 2015 19:21:01 +0100, lee wrote: |
| 2 |
|
| 3 |
> > As 4.9.3 is marked stable, I guess that's what'd you get per |
| 4 |
> > default. |
| 5 |
> |
| 6 |
> 4.8.5 |
| 7 |
> |
| 8 |
> I'd have to run emerge --sync to know about more recent versions. How |
| 9 |
> is that supposed to be used, btw? I only run that when I do want to |
| 10 |
> update everything. Now if I didn't want to update anything but gcc, |
| 11 |
> could I run emerge --sync and install gcc 5.x without having trouble |
| 12 |
|
| 13 |
Emerge --sync only updates the portage tree, so |
| 14 |
|
| 15 |
emerge --sync |
| 16 |
emerge -a sys-devel/gcc:5 |
| 17 |
|
| 18 |
> with anything else I might install before actually updating everything? |
| 19 |
> So if I'd never explicitly update everything but run emerge --sync |
| 20 |
> frequently, things would be updated over time, occasionally? |
| 21 |
|
| 22 |
No, nothing would get updated. To do that you need to run emerge @world |
| 23 |
after emerge --sync. |
| 24 |
|
| 25 |
> > Stuff compiled with older gcc's should run with newer libgcc*[0], but |
| 26 |
> > stuff compililed with a newer gcc might not run with the older |
| 27 |
> > libgcc*. Same goes, with more problems IIRC, for libstdc++. |
| 28 |
> > So beware of that. Apart from that? I'm not aware of problems. |
| 29 |
> |
| 30 |
> Uhm ... So I might break the system by switching between compiler |
| 31 |
> versions? |
| 32 |
|
| 33 |
That's highly unlikely as software that has been compiled with the old |
| 34 |
compiler will still work. You may find that some programs fail to |
| 35 |
recompile with the new compiler, but I didn't experience that with the |
| 36 |
4.9>5 step, although I had some that would build with 4.8 but not 4.9. |
| 37 |
|
| 38 |
I have an application which I would like to compile with gcc |
| 39 |
> 5.x just to see if that's even possible. I could switch, try it, and |
| 40 |
> then switch back. |
| 41 |
|
| 42 |
Exactly, run gcc-config, compile/emerge the program, run gcc-config again. |
| 43 |
|
| 44 |
> > BTW: why is gcc not also handled via eselect? Even if that'd just |
| 45 |
> > call gcc-config? |
| 46 |
|
| 47 |
There was a gcc eselect module but it was dropped in favour of gcc-config |
| 48 |
as it didn't do what was needed of it. This is not unique to gcc, we also |
| 49 |
have binutils-config. As to why no one has written an eselect wrapper for |
| 50 |
either of these, I'd guess it's harder than it sounds or no one who can |
| 51 |
do it feels the need. |
| 52 |
|
| 53 |
|
| 54 |
-- |
| 55 |
Neil Bothwick |
| 56 |
|
| 57 |
Windows Error #02: Multitasking attempted. System confused. |
Archives