Hello Joshua,

* Joshua Baker-LePain ([EMAIL PROTECTED]) [20001113 13:56] thus spake:
> Machine: SGI Indigo2 Impact R10K
> OS: Irix 6.5.8m
> Compilers: MIPSpro 7.30 -- I'd rather not use gcc, since I've heard so
>    many bad things about gcc and Irix, especially network issues, but all
>    that may have changed.  cc defaults to -n32 -mips4

I've experienced this behaviour a while ago on irix-6.5.6 and
the MIPSpro 7.30 (cc -version : MIPSpro Compilers: Version 7.30)

>From what I can gather, you have a few possible solutions until the
compile problem using native irix compiler is resolved: (Anyone
working/aware of this btw?)

- compile with N64 ABI of gcc (it's free of the gcc-induced problem of
  passing small (4-byte) structures on the stack rather than as
  register). You might encounter other problems though, if you link with
  other stuff that is N32 (sloppy typecasts: integer is smaller than
  long and pointer in N64 and casting a pointer into an integer will do harm)
- roll your own gcc-compiled inet_ntoa (from bind, say) and recompile
  gcc. You then use the same incorrect-gcc-but-consistent-way of passing 
  structures not abiding by the N32 MIPS ABI specs.
- use gcc-2.7.x and O32 (old and slower).
- Use the following code and stick somewhere in the amanda code
  (thanks to Stuart Levy for this):

 #if sgi && __GNUC__
 /* Replacement for SGI libc inet_ntoa(), since
  * gcc's structure-passing convention isn't the same as SGI cc's. 
  */
 char *inet_ntoa( struct in_addr sa )
 {
   static char addr[20];
   sprintf(addr, "%d.%d.%d.%d",
     ((unsigned char *)&sa.s_addr)[0], 
     ((unsigned char *)&sa.s_addr)[1],
     ((unsigned char *)&sa.s_addr)[2], 
     ((unsigned char *)&sa.s_addr)[3]);   
   return addr;
 }
 #endif

Of all those, I think the last one is the easiest to implement.

OK, why all this?
Gcc backend passes small (4-bytes) structures on the stack rather than
as a register as the native irix cc compiler expects. As it has been
discussed (ie, beaten to death) on the sgi newsgroups, gcc is at fault
here as it does not follow the N32 MIPS ABI spec, even though it does
it in a 'consistent' way. As long as you don't pass 4-byte structures
by value from a routine in a gcc object to one in the MIPSPro object,
you're OK. Apparently the gcc folks consider this problem to be 'to
hard to be fixed'...(See http://freeware.sgi.com/shared/howto.html#b1)

Stuart Levy <[EMAIL PROTECTED]> has posted that inet_ntoa() (along
with inet_lnaof() and inet_netof()) and semctl() are the only library
functions that take structures by value. semctl() is a big problem for
reasons too long to be explained here, but it is not used in amanda as
far as I can see. The only places I found inet_() functions in the
amanda code are ./common-src/bsd-security.c,
./restore-src/amidxtaped.c and ./server-src/amindexd.c

(Search sgi's newsgroups for inet_ntoa and gcc for all the gory
details: this has been a quick summary. I hope I got this correctly.)

Now, this being said, is anyone aware of a solution to the deps
problem (using the native mipspro compiler)?

Oh, one more thing: this is not, as JJ said, a problem related to
libtool or DSO's on irix, it's just yet another problem ;)

HTH,
jf

> amanda version: 2.4.2 pulled out of CVS today (similar probs with a
> 10/19 CVS grab)
> 
> After a successful ./configure, I get the following output upon trying to
> run gmake (version 3.79.1):
> 
> [jlb@impact amanda]$ gmake 
> Making all in config
> gmake[1]: Entering directory `/home/impact/jlb/src/amanda/config'
> gmake[1]: Leaving directory `/home/impact/jlb/src/amanda/config'
> Making all in common-src
> gmake[1]: Entering directory `/home/impact/jlb/src/amanda/common-src'
> /sbin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../config
> -I./../regex-src  -I/usr/freeware/include   -g   -c alloc.c
> cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src
> -I/usr/freeware/include -g -Wp,-MD,.deps/alloc.pp -c alloc.c -o alloc.o
> cc-1574 cc: ERROR 
>   The definition of macro %sq is not valid.
> 
> 
> cc-1005 cc: ERROR 
>   The source file ".deps/alloc.pp" is unavailable.
> 
> 
> 2 catastrophic errors detected in the compilation of ".deps/alloc.pp".
> Compilation terminated.
> gmake[1]: *** [alloc.lo] Error 1
> gmake[1]: Leaving directory `/home/impact/jlb/src/amanda/common-src'
> gmake: *** [all-recursive] Error 1
> 
> 
> Any ideas?  Thanks.
> 
> -- 
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University

-- 
"You are born naked, wet and hungry. Then it gets worse" -Woto

Reply via email to