> Hopefully this list allows non-sub notes, I just thought the config
> necessary for openssl 0.9.5a on Irix 6.5.4 would be useful to
> somebody.
>
> the config line necessary to build with thread support (make test
> seemed to verify it ok) was:
>
> ./Configure threads -lpthread -L/usr/lib32 irix-mips3-gcc
All options but last are redundant, i.e. './Configure irix-mips3-gcc' is
more than sufficient and the result is equivalent to what you suggest.
If for any reason you really had to add -L/usr/lib32, then something
must be wrong with your gcc installation as the compiler driver should
add this option all by itself.
However it should be explicitly noted that the code generated by gcc is
not binary compatible with code generated by MIPSpro C (the one SGI
compiles libc with:-). Well, almost as it's not like it's totally
incompatible, but only when it comes to passing small structures/unions
by value. http://freeware.sgi.com/Installable/gcc-2.95.2.html states:
quote
[From Jim Wilson] Gcc does not correctly pass/return structures which
are smaller than 16 bytes and which are not 8 bytes. The problem is very
involved and difficult to fix. It affects a number of other targets
also, but irix6 is affected the most, because it is a 64 bit target, and
4 byte structures are common. The exact problem is that structures are
being padded at the wrong end, e.g. a 4 byte structure is loaded into
the lower 4 bytes of the register when it should be loaded into the
upper 4 bytes of the register.
Gcc is consistent with itself, but not consistent with the SGI C
compiler [and the SGI supplied runtime libraries], so the only failures
that can happen are when there are library functions that take/return
such structures. There are very few such library functions. I can only
recall seeing a few of them: inet_ntoa, inet_aton, inet_lnaof,
inet_netof, and semctl.
A possible workaround: if you have a program that calls inet_ntoa and
friends or semctl, and your kernel supports 64-bit binaries (i.e. uname
-a prints IRIX64 rather than just IRIX), then you may compile with gcc
-mabi=64 to workaround this problem.
end-of-quote
It should also be noted that there're couple of inaccuracies. First of
all inet_aton isn't affected as struct in_addr is passed by reference.
Secondly "possible workaround" applies to semctl *only* and not to
"inet_ntoa and friends." It's possible to work all the problems around
by linking with following piece of code:
#ifdef __GNUC__
#if _MIPS_SIM == _ABI64
typedef unsigned long reg_t;
#define REG_T
#elif _MIPS_SIM == _ABIN32
typedef unsigned long long reg_t;
#define REG_T
#endif /* _MIPS_SIM */
#ifdef REG_T
reg_t inet_ntoa (reg_t a0)
{ return _inet_ntoa (a0<<32); }
reg_t inet_lnaof (reg_t a0)
{ return _inet_lnaof (a0<<32); }
reg_t inet_netof (reg_t a0)
{ return _inet_netof (a0<<32); }
reg_t inet_makeaddr (reg_t a0, reg_t a1)
{ reg_t _inet_makeaddr ();
return _inet_makeaddr (a0,a1)>>32;
}
#if _MIPS_SIM != _ABI64
reg_t semctl (reg_t a0, reg_t a1, reg_t a2, reg_t a3)
{ return _semctl(a0,a1,a2,a3<<32); }
#endif /* _MIPS_SIM */
#endif /* REG_T */
#endif /* __GNUC__ */
Appropriate place for it is libgcc.a, (i.e. feel free to 'ar q
/usr/gnu/lib/gcc-lib/mips-sgi-irix6.5/2.95.2/libgcc.a mipspro_fixup.o'
or whatever what is appropriate in your case).
Question of course is what impact does it (the feature) have on OpenSSL?
OpenSSL doesn't call the "offending" functions (your application might
do:-) nor export functions accepting structures by value (at least I
failed to locate one) so that it should be safe to compile OpenSSL with
gcc and even cross-link it with code generated by MIPSpro C.
> #uname -a
> IRIX kind 6.5 04151556 IP32
>
> if you need/want more system info to be put in the config autodetect
> routines, let me know and I'll be happy to provide them
./config does detect gcc and even favours it, i.e. if you have both gcc
and cc installed, it will pick gcc...
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
