Closed Bug 32180 Opened 24 years ago Closed 24 years ago

GTK linking problem

Categories

(SeaMonkey :: Build Config, defect, P3)

SGI
IRIX
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: greg, Assigned: cls)

References

()

Details

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
greg@wildbrain.com - 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
QA Contact: cyeh → leaf
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
[691]	|	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
Closed: 24 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.