On Fri, 6 Feb 2004 21:26:34 -0500
Aron Griffis <agriffis@g.o> wrote:

> Marc Giger wrote:	[Fri Feb 06 2004, 02:14:11PM EST]
> > Yeah, it looks like:-) but I was wrong... I removed this check and
> > ran into troubles. The Macro __GLIBC_HAVE_LONG_LONG must not be
> > defined with ccc. 
> 
> But why not?  I thought your earlier logic made sense.

The following output shows the problems if __GLIBC_HAVE_LONG_LONG is
defined:

make: *** [Parser/acceler.o] Error 1
make: *** Waiting for unfinished jobs....
cc: Error: /usr/include/sys/types.h, line 167: In this declaration,
"int64_t" has no linkage and has a prior declaration in this scope at
line number 27 in file
/usr/lib/compaq/ccc-6.5.9.001-6/alpha-linux/include/sys/types.h.
(nolinkage)__extension__ typedef long long int int64_t;
------------------------------------^
cc: Error: /usr/include/sys/types.h, line 176: In this declaration,
"u_int64_t" has no linkage and has a prior declaration in this scope at
line number 28 in file
/usr/lib/compaq/ccc-6.5.9.001-6/alpha-linux/include/sys/types.h.
(nolinkage)__extension__ typedef unsigned long long int u_int64_t;
---------------------------------------------^
make: *** [Modules/python.o] Error 1

Do you know how to solve it if __GLIBC_HAVE_LONG_LONG is defined?

> 
> > So this check is totally ok! It has nothing to do with
> > "long long". Sorry... I was searching for the reason why I couldn't
> > compile python with ccc.
> > After some time I found it! The attached patch solves the problem.
> > Now I'm running python 2.3 compiled with ccc:-)
> 
> I understand what the patch is doing, but I don't understand why
> defining __GLIBC_HAVE_LONG_LONG wouldn't be a better solution?

See above. I forgot to mention that it is a fix for python only and I
don't know if it should be included in the glibc. I think for other
packages to compile it would need a similar fix in other places, too.
And- so we end nowhere just because we try to solve ccc problems...
This patch was ment to demonstrate only.

> 
> > This seems not to be the right place neither. I think this is
> > useless anyway. The right place to fix it is in
> > "create-comp-config.sh". I tried to change it but it seems that a
> > shell-script and regex guru is needed;-) The same should be changed
> > by cxx (preventing).
> 
> Okay, I think I fixed it.  Try out ccc-6.5.9.001-r1.ebuild when it
> arrives at your nearest mirror...  Let me know what you think.

Cool! I will try it. Thank you!

> 
> > With these two fixes, I'm able to compile a lot more packages with
> > the compaq compiler.
> 
> I'd like to be more certain about the sysmacros.h fix before putting
> it in since it modifies glibc.  It seems like if that fix is needed
> then other header files would need a similar fix!

greets

Marc

--
gentoo-alpha@g.o mailing list