| 1 |
2009/6/26 Ed W <lists@××××××××××.com>: |
| 2 |
> klondike wrote: |
| 3 |
>> |
| 4 |
>>> Apologies for replying to my own post, but I just realised that you |
| 5 |
>>> were posing the question in the context of klondike's blog post. I do |
| 6 |
>>> not know what the status of SSP is in the overlays and/or experimental |
| 7 |
>>> toolchains so I'll bow out and leave it to one of the toolchain gurus |
| 8 |
>>> to provide a credible response. My answer applies to the gcc ebuild in |
| 9 |
>>> the mainline tree. |
| 10 |
>> |
| 11 |
>> Although I may be wrong, AFAIK SSP works nice with almost anything except |
| 12 |
>> libstdc++, also packages which need it to be disabled (ie thunderbird) |
| 13 |
>> usually do it without a problem of after pattching a bit the ebuild. Anyway, |
| 14 |
>> I think the best one to answer is Zorry or Xake as they maintain it. |
| 15 |
> |
| 16 |
> So the Xake overlay is GCC 4.3.2 with the GCC 4 SSP enabled? |
| 17 |
Mainly I could say it is. |
| 18 |
|
| 19 |
> My limited understanding is that the GCC 4 (new) SSP implementation should |
| 20 |
> be relatively benign and supported already by a modern toolchain with no |
| 21 |
> further patches? I would naively assume that since Redhat (and others) seem |
| 22 |
> to be building their distros with it turned on that most packages would |
| 23 |
> already be largely patched upstream to cope with it? (certainly I am more |
| 24 |
> interested in server packages than desktop packages) |
| 25 |
I think Ubuntu has enabled it too. But I don't know how well or bad |
| 26 |
are packages usually supported upstream.. I have run an apache2 server |
| 27 |
and a verlihub server with the toolchain without issues, but I can't |
| 28 |
gurantee you nothing as the server still hasn't had heavy load. |
| 29 |
|
| 30 |
>> Anyway, at least on the overlay uclibc is still not supported :( |
| 31 |
>> http://github.com/Xake/toolchain-overlay/blob/54581c25b74be5a5dc3d8c1de61dba55db7c639f/README |
| 32 |
> |
| 33 |
> Does Xake hang out here? Curious as to what the issues will be found in |
| 34 |
> uclibc. I'm not specially tied to uclibc, just that it seems to work nicely |
| 35 |
> so far and I'm not desperately tight on drive space... |
| 36 |
I don't know the reasons for uclibc being not supported, but I think |
| 37 |
it was because of some compilation problems. (Can't find the tickets, |
| 38 |
sorry). |
Archives