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

Herbert Huber Herbert.Huber@lrz-muenchen.de
Fri, 15 Mar 2002 08:48:37 +0100


This is a multi-part message in MIME format.
--------------38965A984B840CCC03BB216A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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
>
>         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.

Turning off all optimizations and turning an the -Wall flag, I ran into the
same problems as Todd:

Entering directory `/usr/src/openafs-1.2.3/src/rxstat'
/usr/src/openafs-1.2.3/src/pinstall/pinstall rxstat.c
../libafs//afsint/rxstat.c
/usr/src/openafs-1.2.3/src/rxgen/rxgen -x rxstat.xg
make[3]: *** [rxstat.h] Segmentation fault (core dumped)

Strange things are happening here!? ....

So I followed Todds advice to explicitly include <malloc.h>. The compilation
proceeds further and stops at
+ cc -shared -Xlinker -x -o pam_afs.so.1 afs_setcred.o afs_auth.o
afs_account.o afs_session.o afs_password.o afs_pam_msg.o afs_message.o
afs_util.o AFS_component_version_number.o
/usr/src/openafs-1.2.3/lib/libkauth.a /usr/src/openafs-1.2.3/lib/libprot.a
/usr/src/openafs-1.2.3/lib/libubik.a /usr/src/openafs-1.2.3/lib/libauth.a
/usr/src/openafs-1.2.3/lib/librxkad.a /usr/src/openafs-1.2.3/lib/libsys.a
/usr/src/openafs-1.2.3/lib/libdes.a /usr/src/openafs-1.2.3/lib/librx.a
/usr/src/openafs-1.2.3/lib/liblwp.a /usr/src/openafs-1.2.3/lib/libaudit.a
/usr/src/openafs-1.2.3/lib/libcmd.a /usr/src/openafs-1.2.3/lib/libcom_err.a
/usr/src/openafs-1.2.3/lib/util.a -lresolv
/usr/bin/ld: ptuser.o: @gprel relocation against dynamic symbol pruclient

Unfortunately I forgot to mention that I also had this problem, building
OpenAFS with -O2 optimization.
So I skipped the PAM part via commenting out the appropriate lines in the
Makefile. That is surely not the elegant way, but for a first try we can live
without automatic token generation during login and the compilation ends
producing an OpenAFS client as well as an OpenAFS server which can be tested.

Thanks,

Herbert

--------------38965A984B840CCC03BB216A
Content-Type: text/x-vcard; charset=us-ascii;
 name="Herbert.Huber.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Herbert Huber
Content-Disposition: attachment;
 filename="Herbert.Huber.vcf"

begin:vcard 
n:Huber;Herbert
x-mozilla-html:FALSE
org:Leibniz-Rechenzentrum;Gruppe Hochleistungssysteme
adr:;;Leibniz-Rechenzentrum der Bayerischen Akademie der Wissenschafte;München;;D-80333;Germany
version:2.1
email;internet:herbert.huber@lrz-muenchen.de
title:Dr.
x-mozilla-cpt:;0
fn:Herbert Huber
end:vcard

--------------38965A984B840CCC03BB216A--