| 1 |
On Fri, 6 Feb 2004 21:26:34 -0500 |
| 2 |
Aron Griffis <agriffis@g.o> wrote: |
| 3 |
|
| 4 |
> Marc Giger wrote: [Fri Feb 06 2004, 02:14:11PM EST] |
| 5 |
> > Yeah, it looks like:-) but I was wrong... I removed this check and |
| 6 |
> > ran into troubles. The Macro __GLIBC_HAVE_LONG_LONG must not be |
| 7 |
> > defined with ccc. |
| 8 |
> |
| 9 |
> But why not? I thought your earlier logic made sense. |
| 10 |
|
| 11 |
The following output shows the problems if __GLIBC_HAVE_LONG_LONG is |
| 12 |
defined: |
| 13 |
|
| 14 |
make: *** [Parser/acceler.o] Error 1 |
| 15 |
make: *** Waiting for unfinished jobs.... |
| 16 |
cc: Error: /usr/include/sys/types.h, line 167: In this declaration, |
| 17 |
"int64_t" has no linkage and has a prior declaration in this scope at |
| 18 |
line number 27 in file |
| 19 |
/usr/lib/compaq/ccc-6.5.9.001-6/alpha-linux/include/sys/types.h. |
| 20 |
(nolinkage)__extension__ typedef long long int int64_t; |
| 21 |
------------------------------------^ |
| 22 |
cc: Error: /usr/include/sys/types.h, line 176: In this declaration, |
| 23 |
"u_int64_t" has no linkage and has a prior declaration in this scope at |
| 24 |
line number 28 in file |
| 25 |
/usr/lib/compaq/ccc-6.5.9.001-6/alpha-linux/include/sys/types.h. |
| 26 |
(nolinkage)__extension__ typedef unsigned long long int u_int64_t; |
| 27 |
---------------------------------------------^ |
| 28 |
make: *** [Modules/python.o] Error 1 |
| 29 |
|
| 30 |
Do you know how to solve it if __GLIBC_HAVE_LONG_LONG is defined? |
| 31 |
|
| 32 |
> |
| 33 |
> > So this check is totally ok! It has nothing to do with |
| 34 |
> > "long long". Sorry... I was searching for the reason why I couldn't |
| 35 |
> > compile python with ccc. |
| 36 |
> > After some time I found it! The attached patch solves the problem. |
| 37 |
> > Now I'm running python 2.3 compiled with ccc:-) |
| 38 |
> |
| 39 |
> I understand what the patch is doing, but I don't understand why |
| 40 |
> defining __GLIBC_HAVE_LONG_LONG wouldn't be a better solution? |
| 41 |
|
| 42 |
See above. I forgot to mention that it is a fix for python only and I |
| 43 |
don't know if it should be included in the glibc. I think for other |
| 44 |
packages to compile it would need a similar fix in other places, too. |
| 45 |
And- so we end nowhere just because we try to solve ccc problems... |
| 46 |
This patch was ment to demonstrate only. |
| 47 |
|
| 48 |
> |
| 49 |
> > This seems not to be the right place neither. I think this is |
| 50 |
> > useless anyway. The right place to fix it is in |
| 51 |
> > "create-comp-config.sh". I tried to change it but it seems that a |
| 52 |
> > shell-script and regex guru is needed;-) The same should be changed |
| 53 |
> > by cxx (preventing). |
| 54 |
> |
| 55 |
> Okay, I think I fixed it. Try out ccc-6.5.9.001-r1.ebuild when it |
| 56 |
> arrives at your nearest mirror... Let me know what you think. |
| 57 |
|
| 58 |
Cool! I will try it. Thank you! |
| 59 |
|
| 60 |
> |
| 61 |
> > With these two fixes, I'm able to compile a lot more packages with |
| 62 |
> > the compaq compiler. |
| 63 |
> |
| 64 |
> I'd like to be more certain about the sysmacros.h fix before putting |
| 65 |
> it in since it modifies glibc. It seems like if that fix is needed |
| 66 |
> then other header files would need a similar fix! |
| 67 |
|
| 68 |
greets |
| 69 |
|
| 70 |
Marc |
| 71 |
|
| 72 |
-- |
| 73 |
gentoo-alpha@g.o mailing list |
Archives