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.