[OpenAFS-devel] Re: AFS & IA-64?

[Dan Lapine]

On Thu, 14 Mar 2002, Todd L Miller wrote:

> Dan said:
> 
> > We ran into this a while back. No fix available att.
> 
> 	Was the problem understood/localized by then?  It looks like gcc3
> is absolutely convinced that the ALLOC() call in rxgen/rpc_util.c in
> storeval() returns something other than a void * pointer, or that a void *
> pointer is not the same size as a list *.  (This is from, as suggested by
> Nathan, using gdb on rxgen... the returned value looks like it's missing
> the top 0x6000... that characterize the other pointers in the function; as
> chas said:
> 
> > how about a traceback?  this is usally (on the ia64 anyway) failure to
> > prototype functions that involve pointers.  usually the string/memory
> > functions when dealing with afs.
> 
> 	so perhaps gcc3 is convinced it should be casting the
> (hopefully) 64-bit result returned from malloc() into a 32-bit pointer to
> a list?  (OTOH, sizeof( list * ) == sizeof( void * )...))
> 
> > We use gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85).
> 
> 	I tried compiling with cc -v = 
> 
> Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/2.96/specs
> gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)
> 
> 	and the assembler failed with a bunch of "Error: File number less
> than one" messages.  Maybe the gcc3 upgrade blew away the assembler?
> 
> 
> 	On a wild hunch, having tried the line
> 
> void * voidlist = malloc(100);
> 
> 	and been denied by the compiler, I tried explicitly #including
> <malloc.h> -- and, lo and behold, the compiler stopped complaining, and
> the build progressed much further.  (Linker is now complaining about 
> 
> /usr/bin/ld: ptuser.o: @gprel relocation against dynamic symbol pruclient

this is point where we hit the wall. We were told that the ia64 arch has a 
conflict with static vs dynamic symbols

Sorry that I wasn't more explicit in my earlier post. Our workaround has 
been to use an afs translator system serving us the afs fs as an nfs 
mount. Not the best answer, but it works somewhat.

> 
> 	which I will have to track down later.)  My guess is that many
> of the warning's causes will become evident if compiled with
> -Wstrict-prototypes/-Wall, but I don't have the time to check this right
> now.  (I'll try to make time this afternoon.)
> 
> 
> 	So if you (Herbert) would try (a) compiling without optimizations,
> to see if that fixes things (confirm not a compiler bug), and (b) making
> sure everything that's complaining about int/pointer conversions has a
> prototype [I will, as well, but since things aren't building quite right
> for me anyway..], I think we could make some serious progress.
> 
> 	Thanks to all.
> 
> -Todd L. Miller
> 
> 
> 

-- 
---
Daniel LaPine, System Engineer
National Center for Supercomputing Applications (NCSA)
email: dlapine@ncsa.uiuc.edu
phone: 217-244-9294