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)
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.
Reporter | ||
Comment 2•24 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•