Re: glibc-2.3.2-decc-compaq.patch

Marc Giger <[email protected]>
Newsgroups gmane.linux.gentoo.alpha
Message-ID <[email protected]>
On Fri, 6 Feb 2004 21:26:34 -0500
Aron Griffis <[email protected]> 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

--
[email protected] mailing list
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.