Re: IRIX: Expecting n32 objects

[Olaf Weber]

moseley  writes:

> I'm not sure if this is an autoconf or libtool question.  Sorry for 
> the dup post to those on both lists.

> I've got someone trying to build on IRIX 6.5 and they get:

> ./configure --with-zlib=$PUBSROOT/tool/sw/zlib/irix \
> --prefix=$PUBSROOT/tools/sw/swish-e/2.4/irix/ \
> LDFLAGS=-L$PUBSROOT/tool/sw/zlib/irix/lib

> [...]

> gcc -shared  search.o swish2.o swish_words.o proplimit.o rank.o
> db_read.o result_sort.o hash.o compress.o db_native.o ramdisk.o check.o
> error.o list.o mem.o swstring.o docprop.o metanames.o headers.o
> swish_qsort.o date_time.o double_metaphone.o stemmer.o soundex.o
> .libs/libswish-e.lax/libreplace.al/dummy.lo
> -L/data/mw/pubs/tool/sw/zlib/irix/lib -lz -lm -lc  -Wl,-soname
> -Wl,libswish-e.so.3 `test -n "sgi3.0" && echo -Wl,-set_version
> -Wl,sgi3.0` -Wl,-update_registry -Wl,.libs/so_locations -o
> .libs/libswish-e.so.3.0
> ld32: FATAL 12: Expecting n32 objects:
> .libs/libswish-e.lax/libreplace.al/dummy.lo is o32.
> collect2: ld returned 4 exit status
> make[3]: *** [libswish-e.la] Error 1

> I'm not having much luck with google on this.  

> I'm not clear what o32 and n32 are, but it seems odd that they would not 
> be matched since both are built by autotools.

General explanation: IRIX 6.5 systems support two or three ABIs: if
the system has a 32bits kernel (uname reports IRIX) it supports two
32bit ABIs, if it has a 64bit kernel (uname reports IRIX64) it also
supports a 64bit ABI.

The technical differences are that the old 32bit ABI ("o32") only
supports the MIPS I and MIPS II instruction sets, while the new 32bit
ABI ("n32") and the 64bit ABI support the MIPS III and MIPS IV
instruction sets.  The new ABIs also use a more efficient parameter
passing convention, include a 64bit 'long long' type, etc.  As a
consequence, you cannot mix o32 and n32 objects in a single binary.

> "dummy.c" is a dummy C module I always include in my "libreplace". 
> libreplace is for functions that I include in the package and are added
> in if some function is missing on the target platform.  For example
> mkstemp() or vsnprintf().

> I always include "dummy.c" (which is just an empty function) because 
> Solaris was exiting with an error if libreplace was empty.

> Can anyone explain what the issue is here and what I need to do to solve 
> the problem?

The issue is that the linker found an o32 object file while it expects
to link n32 objects.  You'll have to ensure that all objects are
compiled with the same options, and for that matter that the same
compiler is used in all cases.

IIRC gcc 2.x defaults to o32 (and cannot do otherwise) while gcc 3.x
defaults to n32.  You switch using options like '-mabi=64'.

The native compiler (MIPSpro) has n32 as its default (set in
/etc/compiler.defaults) but also obeys the SGI_ABI environment
variable.  Its switches look like this '-o32'/'-32', '-n32', '-64'.

-- 
Olaf Weber

               (This space left blank for technical reasons.)