19 years ago
14 years ago


(Reporter: greg, Assigned: cls)


Firefox Tracking Flags

(Not tracked)





19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.7 [en] (X11; I; IRIX 6.5 IP32)
BuildID:    Didn't get that far, but the tar is dated Mar 16 17:29

Mozilla for IRIX does not properly link to the
App does not start at all.

Reproducible: Always
Steps to Reproduce:
1. type "mozilla" at the command line

Actual Results:  % ./mozilla
.// ./mozilla-bin
13207:./mozilla-bin: rld: Warning: Version Search Suppressed in ./mozilla-bin
Because Object in liblist has non-sgi interface version (0.0)
13207:./mozilla-bin: rld: Fatal Error: Cannot Successfully map soname
'' under any of the filenames

Expected Results:  
Mozilla should start

Seeing that mozilla was having problems finding the libgtk
library, I copied directly to the mozilla 
directory and added "." to the LD_LIBRARYN32_PATH.  This 
didn't help.  The root of the problem seems to be the 
"Object in liblist has non-sgi interface version (0.0)"
error message.  This is not a normal message for just a 
missing library.  The library is found properly by our 
other gtk apps.
Bounce to Build Config.

Assignee: cbegle → cls
Component: Browser-General → Build Config
QA Contact: asadotzler → cyeh - are you having better luck building more recent Mozilla 

Ever confirmed: true
Confirming for triage. There's nothing QA can do with this, as no-one has IRIX.


Comment 4

18 years ago
Greg, are you trying to build using gcc or Irix cc and was gtk/glib/libIDL built
using the same compiler?


18 years ago
QA Contact: cyeh → leaf

Comment 5

18 years ago
Is this something just built, or a downloaded build?
The only Irix build I have seen was for Irix 6.3 dated
Jan 27 2000.
Attempting to run this on Irix 6.5 gives these errors.
Running rld with debug on shows:
  65061: 14:28:40 ./mozilla-bin: failed version match
    /usr/freeware/lib32/ ver sgi1.0:sgi1.1
    against req ver 0.0
  65061:./mozilla-bin: rld: Warning: Version Search
    Suppressed in ./mozilla-bin Because Object
    in liblist has non-sgi interface version (0.0)

Irix 6.3 was a deviation from 6.5, and the compatibility of
shared objects would be very questionable.


Comment 6

18 years ago
When I download the link from the home page [nightly builds] and run it on IRIX
6.5.9, I get this error.  I don't have gcc installed (only sgi compiler) so I
can't test a compiled version.

Comment 7

18 years ago
Ok, I just found out a bit of info that may or may not clear things up here.
Apparently, SGI ships Irix 6.x with *3* separate ABIs! `man abi` for details. 
From the compiler & runtime errors that I've seen, you cannot mix & match object
files & libraries which are compiled with separate ABIs.  If you look at NSPR's & Mozilla's, you'll notice that we are forcing outselves to
use the N32 ABI.  I'm assuming this is because the only xptcall port for Irix is
done against the N32 ABI.  

So, can anyone verify that they are seeing this problem when using gtk libraries
compiled with -n32 ?  Also, I've noticed that I get the original reported error
when I don't have any gtk libraries installed.  (Leaf, when are we going to
start distributing these lgpl'd libs?)

Comment 8

18 years ago
I went through all the gtk and glib Makefiles and added '-n32' to all the
CFLAGS.  However, when I do 'file <filename>' on any of the glib/gtk libraries,
I get the following, since, I believe, this O2 compiles N32 by default:
% file      ELF N32 MSB mips-4 dynamic lib MIPS - version 1

This occurs, of course, for all the libraries.

I went through and modified @CFLAGS@ in all the gtk and glib Makefile.ins and
put an explicit -n32 there, but I still get the same results.  Some of the older
machines (I believe anything pre-R5000, but I'm not sure) still compile O32, and
don't, of course, support N32.  In any case, there are probably more machines
around that don't support N32 than that do, so it would be useful if mozilla
would either support the old abi, or both.

Comment 9

18 years ago
As for compiling and running N32 - SGI has supported N32 compilation and
running since IRIX 6.2.  You must install the sw32 subsystems in order to
get N32 DSO's loaded on your system to be able to run these binaries -
but you can compile N32.  If you wish to force all builds on your IRIX
system to build N32 then create the file /etc/compiler.defaults with:


this will force all builds with IRIX compilers to build MIPS3 N32.

If you want to get rid of all rld version warnings then try setting the

	setenv _RLD_ARGS -ignore_all_versions

that should get rid of those warnings... but be sure you aren't mixing
and matching O32 and N32 DSO's as that simply will not work.

	Victor Riley


Comment 10

18 years ago
Has anyone gotten a build to run once it is successfully compiled?  We currently
have 2 tinderboxes, cement & mason, compiling successfully using irix cc 7.2.1.x
(if I turn off jars anyway) but they fail the alive test.  I get this error:

7038558:./viewer: rld: Error: unresolvable symbol in ./
7038558:./viewer: rld: Fatal Error: this executable has unresolvable symbols

nm -uC | grep Shared
[691]	|	0|	0|FUNC	|GLOB	|DEFAULT	|UNDEF	|nsSharedBufferHandle<unsigned
short>::~nsSharedBufferHandle<unsigned short>(void)

which appears to come from

Comment 11

18 years ago
If I change nsBufferHandle.h so that line 166 says
instead of

and clobber & rebuild xpcom, then that particular undefine goes away and I'm
stuck at another:



scc, does the c++ spec say anything about needing to specify each template
function as

template <class fooT> myClass<fooT>::myFunc<fooT>(args)

Comment 12

18 years ago
bad compiler

the three possibilities for what the compiler is thinking

  (1) the routine exists, but the name was mangled differently
  (2) the routine exists, but wasn't properly exported
  (3) the routine never got instantiated

any of these would be a serious problem in the compiler.  The exact nature of the 
syntax trick that gets past the problem makes me suspect (1) and (3) more.  We 
can test (3) by adding a file that explicitly instantiates the appropriate 
templates.  Chris says he will try this.  Explicit instantiation syntax is, e.g.,

  template class nsSharedBufferHandler<PRUnichar>;

etc., for each needed class or non-member function.  We can test for (2) by 
sticking the appropriate export directives in the template declaration.  If it's 
(1) ... we're kind of screwed.  I hesitate to recommend using the syntax fix 
found to work for IRIX.  As far as I can tell, it _may_ be legal C++ syntax (but 
sort of an edge case) that redundantly specificies the complete (non-
)specialization.  I would not be surprised if (a) this wasn't actually legal 
after all, and/or (b) other compilers choke on the fix.  Chris: you try the 
experiments to see if we can narrow down the problem; I'll see if I can't get a 
better answer as to the legality of the syntax for the fix.

Comment 13

18 years ago
From what I know I would vote for (3). Please see bug#55783 for details. 


Comment 14

18 years ago
scc, I didn't get a chance to test out those theories.  Robert Low discovered
that we need to create the archives with 'CC -ar' (similar to Solaris) in order
to make sure that "template entities required by the objects being archived are
instantiated before creating the archive."  (From Irix CC manpage.)  So I
checked in the fix for that bug, 55783, instead.

WRT the original bug, I'm not sure if there's much more to do besides make sure
that the ancient Irix build from nearly a year ago is removed from the ftp site.
 I'll speak with granrose about adding irix to the nightly build automation.
Does anyone know of an irix equiv of or do we need to actually
host our own n32-built copies of libgtk & friends?

Last Resolved: 18 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.