| 1 |
Mike Frysinger wrote: |
| 2 |
>>>> As we do not do multilib in Prefix, "ia64-hp-hpux*" is 32bit, and I |
| 3 |
>>>> want to hear your thoughts about this additional line there: |
| 4 |
>>>> case ${CHOST} in |
| 5 |
>>>> + ia64-hp-hpux*) ;; # multilib with 32bit default, 64bit |
| 6 |
>>>> is ia64w-hp-hpux* |
| 7 |
>>>> alpha*|hppa64*|ia64*|powerpc64*|mips64*|sparc64*|sparcv9*|x86_64*) |
| 8 |
>>>> gentoo_bug=yes ;; esac |
| 9 |
>>> the check is to catch the majority of users, and it does. i dont want to |
| 10 |
>>> go down this rabbit hole. about we just fix the source code in question |
| 11 |
>>> and call it a day. |
| 12 |
>> AFAICS, it is the only exception to "*64*" being 64bit. |
| 13 |
>> But ok, seems I'll have to mask gcc-4.3 even for hppa-hpux anyway. |
| 14 |
> |
| 15 |
> the fix here though seems like it should be relatively straight forward ? |
| 16 |
> just add a missing #include or #define ? or are there more gcc-4.3 problems |
| 17 |
> than this for that target ? |
| 18 |
|
| 19 |
Unfortunately, on <=hpux11.23 it doesn't help to include <string.h>, |
| 20 |
as it requires _REENTRANT to be defined to declare strtok_r(). |
| 21 |
But I don't think defining _REENTRANT inside gcc.c is a really good idea. |
| 22 |
|
| 23 |
However, now I'm wondering how I was able to merge gcc-4.2.4 at all, |
| 24 |
as it does have the same warnings... |
| 25 |
|
| 26 |
Maybe I'd better do the same as on AIX and always enable the '-pthread' flag, |
| 27 |
also because of this hackery: http://docs.hp.com/en/1896/pthreads.html |
| 28 |
|
| 29 |
Thank you anyway! |
| 30 |
|
| 31 |
/haubi/ |
| 32 |
-- |
| 33 |
Michael Haubenwallner |
| 34 |
Gentoo on a different level |
Archives