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 libgtk-1.2.so. App does not start at all. Reproducible: Always Steps to Reproduce: 1. type "mozilla" at the command line 2. 3. Actual Results: % ./mozilla .//run-mozilla.sh ./mozilla-bin MOZILLA_FIVE_HOME=/wb/people/greg/downloads/package LD_LIBRARY_PATH=/wb/people/greg/downloads/package:/wb/apps/Softimage/Soft3D_3.8SP2/3D/dso:/wb/apps/Softimage/Soft3D_3.8SP2/3D/custom/bin:/wb/apps/Softimage/Soft3D_3.8SP2/3D/custom/dso:/wb/apps/Softimage/Soft3D_3.8SP2/Particle/dso:/wb/apps/Softimage/Soft3D_3.8SP2/3D/dso/softGraphicOGL:/wb/apps/aw/COM/lib:/wb/apps/aw/maya/bin/plug-ins:/wb/apps/aw/maya/lib:/wb/apps/aw/studiopaint9.0/installsysfiles/ImageVision/filefmt:/wb/apps/aw/studiopaint9.0/lib:/wb/apps/aw/studiopaint9.0/plug-ins:/wb/apps/mi/shaders:/wb/apps/mi/mayatomi/lib:/wb/apps/mi/mayatomi: SHLIB_PATH=/wb/people/greg/downloads/package LIBPATH=/wb/people/greg/downloads/package MOZ_PROGRAM=./mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= 13207:./mozilla-bin: rld: Warning: Version Search Suppressed in ./mozilla-bin Because Object libgtk-1.2.so in liblist has non-sgi interface version (0.0) 13207:./mozilla-bin: rld: Fatal Error: Cannot Successfully map soname 'libgtk-1.2.so' under any of the filenames ./libgtk-1.2.so:/wb/apps/Softimage/Soft3D_3.8SP2/3D/dso/libgtk-1.2.so:/wb/apps/Softimage/Soft3D_3.8SP2/3D/custom/bin/libgtk-1.2.so:/wb/apps/Softimage/Soft3D_3.8SP2/3D/custom/dso/libgtk-1.2.so:/wb/apps/Softimage/Soft3D_3.8SP2/Particle/dso/libgtk-1.2.so:/wb/apps/Softimage/Soft3D_3.8SP2/3D/dso/softGraphicOGL/libgtk-1.2.so:/wb/apps/aw/COM/lib/libgtk-1.2.so:/wb/apps/aw/maya/bin/plug-ins/libgtk-1.2.so:/wb/apps/aw/maya/lib/libgtk-1.2.so:/wb/apps/aw/studiopaint9.0/installsysfiles/ImageVision/filefmt/libgtk-1.2.so:/wb/apps/aw/studiopaint9.0/lib/libgtk-1.2.so:/wb/apps/aw/studiopaint9.0/plug-ins/libgtk-1.2.so:/wb/apps/mi/shaders/libgtk-1.2.so:/wb/apps/mi/mayatomi/lib/libgtk-1.2.so:/wb/apps/mi/mayatomi/libgtk-1.2.so:/usr/lib32/libgtk-1.2.so:/usr/lib32/internal/libgtk-1.2.so:/lib32/libgtk-1.2.so:/opt/lib32/libgtk-1.2.so: % Expected Results: Mozilla should start Seeing that mozilla was having problems finding the libgtk library, I copied libgtk-1.2.so 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 libgtk-1.2.so 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. Gerv
Assignee: cbegle → cls
Component: Browser-General → Build Config
QA Contact: asadotzler → cyeh
firstname.lastname@example.org - are you having better luck building more recent Mozilla releases? Gerv
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirming for triage. There's nothing QA can do with this, as no-one has IRIX. Gerv
Greg, are you trying to build using gcc or Irix cc and was gtk/glib/libIDL built using the same compiler?
Status: NEW → ASSIGNED
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/libgtk-1.2.so ver sgi1.0:sgi1.1 against req ver 0.0 65061:./mozilla-bin: rld: Warning: Version Search Suppressed in ./mozilla-bin Because Object libgtk-1.2.so 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. Rob
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.
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 Irix.mk & Mozilla's configure.in, 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?)
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 libgtk-1.2.so.1.3 libgtk-1.2.so.1.3: 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.
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: -DEFAULT:abi=n32:isa=mips3 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 following: 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 SGI
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 ./libxpcom.so: __dt__30nsSharedBufferHandle__pt__3_UsGv 7038558:./viewer: rld: Fatal Error: this executable has unresolvable symbols nm -uC libxpcom.so | grep Shared  | 0| 0|FUNC |GLOB |DEFAULT |UNDEF |nsSharedBufferHandle<unsigned short>::~nsSharedBufferHandle<unsigned short>(void) which appears to come from http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsBufferHandle.h#166
If I change nsBufferHandle.h so that line 166 says nsSharedBufferHandle<CharT>::~nsSharedBufferHandle<CharT>() instead of nsSharedBufferHandle<CharT>::~nsSharedBufferHandle() and clobber & rebuild xpcom, then that particular undefine goes away and I'm stuck at another: __ct__35basic_nsPromiseFlatString__pt__3_UsGRC33basic_nsAReadableString__pt__3_Us aka http://lxr.mozilla.org/seamonkey/source/xpcom/ds/nsAReadableString.h#1433 scc, does the c++ spec say anything about needing to specify each template function as template <class fooT> myClass<fooT>::myFunc<fooT>(args) ?
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.
From what I know I would vote for (3). Please see bug#55783 for details.
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 sunfreeware.com or do we need to actually host our own n32-built copies of libgtk & friends?
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.