| 1 |
On 02/15/2013 12:11 PM, Konstantin Tokarev wrote: |
| 2 |
> 14.02.2013, 12:10, "Michael Haubenwallner" <haubi@g.o>: |
| 3 |
>> Another reason to avoid glibc on proprietary Unix systems is supportability: |
| 4 |
>> Unix vendors unlikely would support such setups, so even when there's a bug |
| 5 |
>> in their kernel, we'd be on our own. Same basically stands for binutils. |
| 6 |
>> |
| 7 |
>> Example: Currently I'm working with AIX kernel developers to nail down why a |
| 8 |
>> (quite large) C++ executable built with (my old stable snapshot of) Prefix' |
| 9 |
>> gcc-4.2.4 does not start on aix7.1 - it does not even enter main(), while it |
| 10 |
>> works on aix5.3 and aix6.1. They tried to close the report when they heard of |
| 11 |
>> gcc, but continued when they were told that gcc just generates assembler code |
| 12 |
>> subsequently processed by their native binutils. |
| 13 |
> |
| 14 |
> Out of curiosity: how does glibc prevent you from using native binutils? |
| 15 |
|
| 16 |
Well, technically it does not. However, both libc and binutils are playing in a |
| 17 |
similar league that could be named like "core unix system", and I do expect any |
| 18 |
proprietary vendor to refuse support when using another either libc or binutils. |
| 19 |
|
| 20 |
/haubi/ |
Archives