Closed Bug 67912 Opened 24 years ago Closed 24 years ago

Irix6.5 0.7 nightly binaries don't look for gtk in freeware

Categories

(SeaMonkey :: Build Config, defect)

SGI
IRIX
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: rob, Assigned: cls)

Details

In the past the Mozilla binaries successfully found the freeware libraries
such as GTK and GLIB in the standard Irix installation directory:
/usr/freeware/lib32.

My understanding of this is that the compile/link option -L/usr/freeware/lib32
would put this in the liblist which would be searched at runtime for DSOs
that needed to be loaded.

The only thing I can think of that would have changed this is that the build
environment for the Mozilla binaries (hostname "cement") has changed such
that GTK is no longer installed under the standard freeware path.
Not sure what's going on, but the nightly builds from cement have always built
against the n32 gtk libs I installed in /opt/local-n32 (before I knew freeware
existed).  I tested the 0.7 build on a machine with only the freeware libs
installed and it worked fine.  I haven't tested a nightly recently though.

This is one of the errors I'm getting after running mozilla:
**************************************************
nsNativeComponentLoader: SelfRegisterDll
(/projects/sise/mozilla/devel/bin/robs/package/components/libgfx_gtk.so) Load 
FAILED with error: 19570810:./mozilla-bin: rld: Fatal Error: Cannot 
Successfully map soname 'libgtk-1.2.so.1' under any of the filenames ./libgtk-
1.2.so.1:/usr/lib32/libgtk-1.2.so.1:/usr/lib32/internal/libgtk-
1.2.so.1:/lib32/libgtk-1.2.so.1:/opt/lib32/libgtk-1.2.so.1:./libgtk-
1.2.so.1.1:/usr/lib32/libgtk-1.2.so.1.1:/usr/lib32/internal/libgtk-
1.2.so.1.1:/lib32/libgtk-1.2.so.1.1:/opt/lib32/libgtk-1.2.so.1.1: 
**************************************************
This was from the 0.6 release for Irix 6.5 I just tried (to check if
something had changed).  Maybe I was mistaken in thinking that something
has changed (as most of my work has been building binaries locally), and
perhaps I've always had to set LD_LIBRARY_PATH to include freeware.

So how are other people finding the freeware libraries?

Doing an "elfdump -L" on some of the DSOs shows freeware in the RPATH
for my locally built graphics releated DSOs, but not in those from the
mozilla release or nightly binaries.
My guess is that everyone is explicitly setting LD_LIBRARY_PATH to include
/usr/freeware/lib32.  I just tested again with a current tree build (before it
went red) and it still worked on concrete once I set LD_LIBRARY_PATH.  Setting
LD_LIBRARY_PATH should be an acceptible fix as opposed to adding a hardcoded
rpath for libs that are not distributed with the system and are otherwise not
part of the build. Marking wontfix.

Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
verified wontfix.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.