Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
GCC 4.5 testing
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 8, 9, 10 ... 13, 14, 15  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
rhill
Retired Dev
Retired Dev


Joined: 22 Oct 2004
Posts: 1629
Location: sk.ca

PostPosted: Tue Aug 03, 2010 6:24 am    Post subject: Reply with quote

There's multiple patchsets that have to be checked and repackaged.
_________________
by design, by neglect
for a fact or just for effect
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7206
Location: Austria

PostPosted: Tue Aug 03, 2010 7:06 am    Post subject: Reply with quote

I took the ones from the 4.5.1 pre9999 ebuild and it worked (basically stripped out the svn parts of it).
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
xibo
Apprentice
Apprentice


Joined: 21 Aug 2007
Posts: 152
Location: moving between kubuntu and ubuntu kde edition

PostPosted: Tue Aug 03, 2010 7:22 am    Post subject: Reply with quote

devsk wrote:
dirtyepic wrote:
I was hoping to do it today but I got busy. :?
I'm off working pipeline the rest of the week so if no one else gets to it, it'll be next weekend for sure.
Is it as easy as renaming 4.5.0 ebuild to 4.5.1? Or there is more to it? like manual patches?

no, you just need to remove the version-dependent patches: gcc-4.5.1.ebuild
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7206
Location: Austria

PostPosted: Tue Aug 03, 2010 10:46 am    Post subject: Reply with quote

For some reason, due to(?) recompiling system wicd can't dhcp into a wired network anymore. dhcpcd eth0 works just fine though...
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
xibo
Apprentice
Apprentice


Joined: 21 Aug 2007
Posts: 152
Location: moving between kubuntu and ubuntu kde edition

PostPosted: Tue Aug 03, 2010 11:16 am    Post subject: Reply with quote

genstorm wrote:
For some reason, due to(?) recompiling system wicd can't dhcp into a wired network anymore. dhcpcd eth0 works just fine though...

i've had that behaviour months ago with linux kernel 2.6.35-rc4, reverting to 2.6.34 made my intel e1000 card work as expected again. same problem with 2.6.35-rc5 and rc6, so probably you have updated to the "stable" 2.6.35 while updating to gcc-4.5.1, and in "stable" it's not working either.

as i had no trouble with my realtec card with any of those versions i considered it a kernel-internal inconsistency or suboptimal driver development attempt and thought it would be fixed or reverted before "stable" though.

EDIT: typoes
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7206
Location: Austria

PostPosted: Tue Aug 03, 2010 11:23 am    Post subject: Reply with quote

Could indeed be so, easiest test will be one restart into an older kernel. Thx!
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
Etal
Veteran
Veteran


Joined: 15 Jul 2005
Posts: 1696

PostPosted: Tue Aug 03, 2010 2:46 pm    Post subject: Reply with quote

xibo wrote:
genstorm wrote:
For some reason, due to(?) recompiling system wicd can't dhcp into a wired network anymore. dhcpcd eth0 works just fine though...

i've had that behaviour months ago with linux kernel 2.6.35-rc4, reverting to 2.6.34 made my intel e1000 card work as expected again. same problem with 2.6.35-rc5 and rc6, so probably you have updated to the "stable" 2.6.35 while updating to gcc-4.5.1, and in "stable" it's not working either.

as i had no trouble with my realtec card with any of those versions i considered it a kernel-internal inconsistency or suboptimal driver development attempt and thought it would be fixed or reverted before "stable" though.

EDIT: typoes


A few people seem to have the same problem, and there's a thread about it here.
Back to top
View user's profile Send private message
Need4Speed
Guru
Guru


Joined: 06 Jun 2004
Posts: 497

PostPosted: Tue Aug 03, 2010 3:15 pm    Post subject: Reply with quote

Has anyone succeeded in building gcc-4.5 with gcj? I've tried both the 4.5.0 ebuild in portage and the 4.5.1 ebuild xibo posted, but for both I get:
Code:
make[3]: *** No rule to make target `classpath/tools/tools.zip', needed by `classpath/tools/libgcj_tools_la-tools.lo'.  Stop.

_________________
2.6.34-rc3 on x86_64 w/ paludis
WM: ratpoison
Term: urxvt, zsh
Browser: uzbl
Email: mutt, offlineimap
IRC: weechat
News: newsbeuter
PDF: apvlv
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3260
Location: Gainesville, Florida

PostPosted: Wed Aug 04, 2010 1:58 am    Post subject: Reply with quote

FWIW, I just used the gcc-4.5.1 ebuild posted by xibo (Thanks much!), emerged fine, and then got through an emerge -e @system (166 packages) on my ~amd64 Gentoo, no problems. Enabled graphite, but no lto. All seems normal so far. :)

I just added it to /usr/portage/sys-devel/gcc, and digested. Figured the offical 4.5.1 will be in portage shortly, so I didn't bother with an overlay.

Correct me if I'm wrong, but if the combination -flto -fwhole-program produces a binary of about half the size than without, wouldn't this imply that for years gcc has been producing very bloated/unclean code? If this holds typical for most packages compiled with -flto -fwhole-program , wouldn't the potential for improvement on many levels be remarkable, or even amazing?

If we can't yet enable this globally any time soon, I could really get behind doing it on a package-by-package basis as dirtyepic mentioned, even if it is a little trouble. Wish I'd have thought to record sizes of the binaries before/after when I enabled LTO on that emerge -e @world. :roll:

Is there a simple little terminal command that would output the current size of all the installed binaries listed? Like, what's shown in a dolphin window of /usr/bin in the "details" view mode?
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2870
Location: Bay Area, CA

PostPosted: Wed Aug 04, 2010 2:27 am    Post subject: Reply with quote

wrc1944 wrote:
Is there a simple little terminal command that would output the current size of all the installed binaries listed? Like, what's shown in a dolphin window of /usr/bin in the "details" view mode?
Here you go:
Code:
#!/bin/bash
for i in $(qlist -CI | sort -u) ; do qsize -C $i ; done | awk '{print $6,$1}' | sort -nu
Sorted list is a bonus I threw in.... :wink: :lol:
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3260
Location: Gainesville, Florida

PostPosted: Wed Aug 04, 2010 3:37 am    Post subject: Reply with quote

devsk,
I really appreciate it the lightning-fast reply, :) but I must be doing something wrong, as nothing seems to match up. :roll: I ran the command in /usr/bin, and got, for example:
Code:
133.196 app-admin/eselect-1.2.11:
However, in dolphin "details" view eselect size is 4.7Kb.
dir -list -h gives me:
Code:
 257402  8.0K -rwxr-xr-x 1 root root     4.7K Aug  3 19:28 eselect
This would be usable- I could just copy that output to a text file before enabling lto and then emerging packages, and then compare sizes afterwards.

I understand the qlist and pipe parts of your command, but need to look up awk stuff, so I understand better what the intent is. I'm pretty ignorant of anything beyond the very basic stuff.

Thanks again!
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2870
Location: Bay Area, CA

PostPosted: Wed Aug 04, 2010 4:07 am    Post subject: Reply with quote

It doesn't matter where you run that one line from, if you typed it correctly, you should get a set of lines with "<size in KB> <pkg name>" in each line, sorted on the size of the package.

Can you cut & paste the output of the command when you typed it in a terminal?
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2870
Location: Bay Area, CA

PostPosted: Wed Aug 04, 2010 4:42 am    Post subject: Reply with quote

I took xibi's 4.5.1 ebuild and just did a quick compile of gimp and mplayer with -flto, both of which failed (mplayer with 'syntax error', and gimp with libtool error). Did anybody else see that?

Without -flto, both compiled with -floop optimizations. gimp size went up, mplayer size went down. Compile times are slightly longer but almost same as 4.4.4. Not sure if I am ready to jump onto 4.5.1 bandwagon yet!
Back to top
View user's profile Send private message
xibo
Apprentice
Apprentice


Joined: 21 Aug 2007
Posts: 152
Location: moving between kubuntu and ubuntu kde edition

PostPosted: Wed Aug 04, 2010 10:31 am    Post subject: Reply with quote

wrc1944 wrote:
FWIW, I just used the gcc-4.5.1 ebuild posted by xibo (Thanks much!), emerged fine, and then got through an emerge -e @system (166 packages) on my ~amd64 Gentoo, no problems. Enabled graphite, but no lto. All seems normal so far. :)

Having been considering to completely reinstall one of my boxes for some time now, I decided gcc-4.5.1's release to be a good day to actually do so. So far i had tons of problems due to me being too picky ( i wanted postgres instead of mysql, zsh instead of bash, ... ), but none of those were gcc's fault IMO. In the meantime i have a working kde-4.5 installation that has completely been built by gcc-4.5.1 . I didn't use lto though.

Quote:
Correct me if I'm wrong, but if the combination -flto -fwhole-program produces a binary of about half the size than without, wouldn't this imply that for years gcc has been producing very bloated/unclean code? If this holds typical for most packages compiled with -flto -fwhole-program , wouldn't the potential for improvement on many levels be remarkable, or even amazing?

No. Eventually programs were larger then they were required to be. However, in general you can't just omit symbols or code just because they're not referenced. Imagine an inline assembler snipped that calls or jumps to a label/symbol that is located at an address which is determined on runitme, or even worse obtained from an file or network socket...

Rather then -flto, I'd be interested in building world with -Os . Effectively that was impossible in the days of gcc-3.x, half a year ago i retried it when creating a network boot "image" and all packages were compilng ( at least those who compiled with -O2 also compiled with -Os ), but i had some programs crashing at random, which stopped after I rebuilt the installation with -O2...
... are there any -Os users around that can give me a hint? :P
Back to top
View user's profile Send private message
asturm
Developer
Developer


Joined: 05 Apr 2007
Posts: 7206
Location: Austria

PostPosted: Wed Aug 04, 2010 10:40 am    Post subject: Reply with quote

I had a complete system compiled with -Os on my old laptop (small cache and memory), that was back in the gcc-4.2.x and gcc-4.3.x days, no issues then.
_________________
backend.cpp:92:2: warning: #warning TODO - this error message is about as useful as a cooling unit in the arctic
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3793

PostPosted: Wed Aug 04, 2010 10:52 am    Post subject: Reply with quote

Quote:
are there any -Os users around that can give me a hint?


been there and it was painfull.
First you have to modifiy quite a lot of ebuilds that filter -Os out and, as you say, you will start to see runtime problems ( glibc segfaults f.ex., uclibc had problems too IIRC).
Apart from that i was more interested in binary size and memory footprint differences and at least in my experience binary size difference between -Os and -O2 wasn´t that much. In a embedded device ( and i mean a _really_ small device) it maybe makes sense but for a desktop computer it is a waste of time IMO and there are probably other optimizations to make if you are really looking for small binaries.

this was a few years ago BTW, with gcc-4.something, i suppose things are different ( better?) now.

cheers
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3260
Location: Gainesville, Florida

PostPosted: Wed Aug 04, 2010 2:11 pm    Post subject: Reply with quote

@xibo,
Thanks much for the info- very informative and makes perfect sense. :) On the -Os topic, I had all my Gentoo systems using -Os for about a year or two, with gcc-4.2.x, and 4.3.x, and had the same experience as genstorm. No problems I can remember. However, IIRC I did add 2 or 3 -O2 flags I thought were important to my make.conf, so I guess strictly speaking it wasn't a pure -Os system. I changed back to -O2 plus a few other flags recently, but I never checked the size of the binaries with either flag. Wish I had.

@devsk,
I'm not on Gentoo right now, but will try again and post back when I am later today. However, all the lines were similar to the eselect line I used as an example. I'll use pastebin, as it was a very long list.
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental


Last edited by wrc1944 on Wed Aug 04, 2010 3:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
devsk
Advocate
Advocate


Joined: 24 Oct 2003
Posts: 2870
Location: Bay Area, CA

PostPosted: Wed Aug 04, 2010 3:19 pm    Post subject: Reply with quote

wrc1944 wrote:
@devsk,
I'm not on Gentoo right now, but will try again and post back when I am later today. However, all the lines were similar to the eselect line I used as an example. I'll use pastebin, as it was a very long list.
No need to paste anything. I thought you said it only gave you one line of output.

The command output is a sorted list of package size and pkg name. This can not be compared with 'dir -list -h' output. They are two different things. Also, you did not specify which directory you did your 'dir -list -h' from.

The command I gave you is the real size of each package installed on your system in KBs. You can confirm that by saying 'q size openoffice' and then searching for openoffice in the output. HTH.
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3260
Location: Gainesville, Florida

PostPosted: Wed Aug 04, 2010 3:32 pm    Post subject: Reply with quote

Thanks much for the clarifications.
Sorry to clutter up this thread with basic stuff I should know and/or remember. :oops: Guess I sort of went off on a tangent about binary sizes with/without LTO. :roll:
_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
Kingoftherings
Guru
Guru


Joined: 04 May 2008
Posts: 328

PostPosted: Wed Aug 04, 2010 7:26 pm    Post subject: Reply with quote

Has the chromium search bar bug been fixed in 4.5.1?
I tried 4.5.0 a while ago, and I couldn't do Google searches from the url/search bar. So I had to go back to 4.4.x.
Back to top
View user's profile Send private message
Bobbycar
n00b
n00b


Joined: 25 Feb 2009
Posts: 8

PostPosted: Wed Aug 04, 2010 7:47 pm    Post subject: Reply with quote

Kingoftherings wrote:
Has the chromium search bar bug been fixed in 4.5.1?

No, not here with chromium-6.0.472.14
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Wed Aug 04, 2010 8:27 pm    Post subject: Reply with quote

Bobbycar wrote:
Kingoftherings wrote:
Has the chromium search bar bug been fixed in 4.5.1?

No, not here with chromium-6.0.472.14


of course it can't - it would be a package-specific fix

the 2 solutions are:

1) either google "fixes" their "issue" (even if it's more of a kind of gcc induced trouble)

2) the ebuild shall append -fno-ipa-cp in the future
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
xibo
Apprentice
Apprentice


Joined: 21 Aug 2007
Posts: 152
Location: moving between kubuntu and ubuntu kde edition

PostPosted: Wed Aug 04, 2010 11:18 pm    Post subject: Reply with quote

Quote:
Thanks much for the info- very informative and makes perfect sense. :) On the -Os topic, I had all my Gentoo systems using -Os for about a year or two, with gcc-4.2.x, and 4.3.x, and had the same experience as genstorm. No problems I can remember. However, IIRC I did add 2 or 3 -O2 flags I thought were important to my make.conf, so I guess strictly speaking it wasn't a pure -Os system. I changed back to -O2 plus a few other flags recently, but I never checked the size of the binaries with either flag. Wish I had.


So, it's posible and i'm doing something wrong I guess. My attempt was to write `CFLAGS="-march=core2 -Os" \ CXXFLAGS="-march=core2 -Os"` into my make.conf . I don't mind emerge replacing Os by O2 on certain packages that are known to not work with Os.
Having been programming C and using majorly gcc for more then a decade now I had my full share of Os trouble on my own applications ( Os is a good array bounds validator when valgrind can't be used ), though in nearly all cases that was my fault rather then gcc's. The only two cases I couldn't so far resolve are [1] a gcc bug (internal compiler exception so it was quite obvious it's not (solely) my fault) that was fixed for 3.5/4.0 by someone else __long_ago__ and [2] a scipt interpreter that allows any function somehow linked into the application to be called from a script being loaded on runtime without bindings or wrappers by using alot of inline assembler to evaluate the addresses and order the parameters - ie doing one of the most platform dependent things i can imagine.

I guess asking for all of portage to completely build and work with Os ( while also being able to build and work with O2 at the same time ) is like asking for the web to become valid html/js - i.e. asking for the impossible. Although I wouldn't mind to see ONE cms which generates valid strict xhtml and at the same time allows me to choose which dbms to use before the web dies ( which i am pretty sure to happen before i die considering how nothing conforms to the standards and webdevs curse browsers that handle their undefined behavior a different way they intend it to be handled ). Hmmm I'm trolling offtopic ...

gringo wrote:
Apart from that i was more interested in binary size and memory footprint differences and at least in my experience binary size difference between -Os and -O2 wasn´t that much.


It's true -Os won't decrease binary size as much as most linker optimizations which drop code, elf metadata or C++ OOP overhead.
Os however will reduce the size of the code that is executed, which lto or whole-program do not, as those just emit unreferenced sections.
The evil that can be fought with Os is named instruction cache misses. I don't know numbers or statistics but if assuming electronic signals to move at the speed of light, and diving that speed by 10^9 to represent the GHz frequency of a CPU, then dividing it by 10 again to represent switching time of the "routing" elements on the path, the CPU is quite alot of clocks away from the memory modules. and the signal's reply needs to have come back for the CPU to be able to continue execution - and actually a sequence of signals is required instead of just one. I guess that's also why the size-bloated -O3 -funroll-loops binaries often enough run slower then their -O2 counterparts, even though every safed loop-condition missprediction safed by -funroll-loops safes 32 clocks and each loop iteration furthermore requires a compare and eventually also an addition less which yield in 1(or 2) instructions per iteration (on a core2).
lto will not change cache hit counts drastically, as unrefenced functions are in most cases not even going to get loaded into the cache.

I become quite thoughtfull about instruction cache misses when a certain applications that love making long jumps have several MiB sized CODE sections...
Maybe I'm thinking too much about this, when all I need to make my apps run faster is more clock rate*.

The obvious binary size solution would be -Os -flto, but both have issues these days, and if I were to chose which one is more important i'd go with Os, as HDDs and NFS are sufficiently fast in sequencial access ( "program loading" ), the symbol table is a red black tree which makes the safings of reducing the number of symbols by something not at least 99% considerably low, and the rutime memory safing will go away sooner or later when linux learns to properly distinguish data from code and to share the code and constants of the same DLLs between multiple running programs that are linked to it. Linux can actually do this partially already AFAIK.

*if thinking about it the idea comes close that higher clock rates won't make signals move faster or memory get closer, and therefore just result in more clocks passing in idle state waiting for new code to arrive, but then again i'm probably thinking too much
Back to top
View user's profile Send private message
wrc1944
Advocate
Advocate


Joined: 15 Aug 2002
Posts: 3260
Location: Gainesville, Florida

PostPosted: Fri Aug 06, 2010 1:06 pm    Post subject: Reply with quote

Just sync'd, and noticed a gcc-4.5.0 ebuild in portage. I was getting ready to move my main box to 4.5, and was waiting for 4.5.1 in portage, as dirtyepic mentioned this weekend for sure. Is that still on?

If not, I was going to use xibo's 4.5.1 ebuild, which worked fine on two other boxes. However, if it's only a few days until an "official" 4.5.1 in portage, I might wait for that. Will there be any reason to wait (like extra patches included), or will there really be no meaningful difference between xibo's and the as yet non-existent portage 4.5.1 ebuild?

The only differences in xibo's 4.5.1 and the existing portage 4.5.0 are that xibo doesn't include these lines:
Quote:
PATCH_VER="1.4"
UCLIBC_VER="1.0"

# Hardened gcc 4 stuff
PIE_VER="0.4.5"
SPECS_VER="0.2.0"
SPECS_GCC_VER="4.4.3"
# arch/libc configurations known to be stable with {PIE,SSP}-by-default
PIE_GLIBC_STABLE="x86 amd64 ppc ppc64 arm ia64"
PIE_UCLIBC_STABLE="x86 arm amd64 ppc ppc64"
SSP_STABLE="amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP support"
SSP_UCLIBC_STABLE=""
#end Hardened stuff
and comments out the sed PR33200 line:
Quote:
# PR33200 has been fixed ages ago on mainstream
# sed -i 's/use_fixproto=yes/:/' gcc/config.gcc #PR33200

_________________
Main box- AsRock x370 Gaming K4
Ryzen 1700, 3.0GHz, 16GB GSkill Flare DDR4 3200mhz
Samsung SATA 1000GB, Radeon HD R7 350 2GB DDR5
Gentoo ~amd64 plasma, glibc-2.30-r2, gcc-9.2.0 kernel-5.4.1-gentoo USE=experimental
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 6111
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Fri Aug 06, 2010 1:39 pm    Post subject: Reply with quote

wrc1944 wrote:
Just sync'd, and noticed a gcc-4.5.0 ebuild in portage. I was getting ready to move my main box to 4.5, and was waiting for 4.5.1 in portage, as dirtyepic mentioned this weekend for sure. Is that still on?

If not, I was going to use xibo's 4.5.1 ebuild, which worked fine on two other boxes. However, if it's only a few days until an "official" 4.5.1 in portage, I might wait for that. Will there be any reason to wait (like extra patches included), or will there really be no meaningful difference between xibo's and the as yet non-existent portage 4.5.1 ebuild?

The only differences in xibo's 4.5.1 and the existing portage 4.5.0 are that xibo doesn't include these lines:
Quote:
PATCH_VER="1.4"
UCLIBC_VER="1.0"

# Hardened gcc 4 stuff
PIE_VER="0.4.5"
SPECS_VER="0.2.0"
SPECS_GCC_VER="4.4.3"
# arch/libc configurations known to be stable with {PIE,SSP}-by-default
PIE_GLIBC_STABLE="x86 amd64 ppc ppc64 arm ia64"
PIE_UCLIBC_STABLE="x86 arm amd64 ppc ppc64"
SSP_STABLE="amd64 x86 ppc ppc64 arm
# uclibc need tls and nptl support for SSP support"
SSP_UCLIBC_STABLE=""
#end Hardened stuff
and comments out the sed PR33200 line:
Quote:
# PR33200 has been fixed ages ago on mainstream
# sed -i 's/use_fixproto=yes/:/' gcc/config.gcc #PR33200


yes !

if you don't use hardened, the hardened stuff can be left uncommented,

anyways I'd suggest to wait since the new 1.4 patchset (for 4.5.0) already includes a critical fix for the issue that you can't switch between gcc-versions anymore:
https://bugs.gentoo.org/show_bug.cgi?id=317059
https://bugs.gentoo.org/show_bug.cgi?id=329381

which surely will be ported to 4.5.1 soon (it failed for me)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.9.0
https://github.com/kernelOfTruth/pulseaudio-equalizer-ladspa

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3 ... 8, 9, 10 ... 13, 14, 15  Next
Page 9 of 15

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum