101839 - M0.9.4 missing llibraries

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Sim Alam]

M0.9.4 milestone build for Compaq Tru64 4.x builds are missing the following
libraries:
libglib-1.2.so
libgmodule=1.2.so
libgdk-1.2.so
libgtk-1.2.so

Comment 1

[hacker formerly known as [e-mail]]

This is not a bug.  None of the unix builds contain the system libraries they 
are compiled against.  I do not know the url to a binary distribution of those 
libraries off the top of my head, but you should be able to build the libraries 
from their standard source distributions.  

Comment 2

[Jon Granrose]

verified invalid.

Comment 3

[Sim Alam]

These libraries are not part of the Tru64 system installs. They have always 
been included in the OSF/Tru64 milestone builds - though M0.9.3 missed them in 
the initial build and added them in a revised build shortly after.

Comment 4

[cls]

They are not part of the standard mozilla.org distributions either.  It sounds
like whoever contributed the milestone binaries prior to 0.9.3 was generous
enough to include the libraries.  I believe Jim Nance is created the latest
milestone binaries so I'm reassigning this to him.  Regardless, this is should
not be a bug as none of the binaries are guaranteed to run "out of the box".

Comment 5

[Sim Alam]

Fair enough. Maybe you need to make this more clear in the release notes?

Comment 6

[jim_nance]

FWIW, when I build milestones I put the gtk libs into dist/bin before I build
the packages, and I also put the source for them in there too.  That ensures that
they run and are legal to distribute.

Comment 7

[Sim Alam]

Jim, does your comment mean that the 0.9.4 milestone builds for Tru64 should
include those libraries?

Comment 8

[jim_nance]

No, I did not do the 0.9.4 milestone builds.  Let me give it a try and Ill post
the binaries.  It will take a few days.  Its a very slow machine.

Comment 9

[Chase Tingley]

Does 0.9.5 have the same problem?  Marking NEW for now.

Comment 10

[Sim Alam]

Can't confirm that 0.9.5 has the "problem" as the builds for Tru64 4.x haven't
been done yet.

Comment 11

[Jon Granrose]

QA to [e-mail] since he'll be able to verify this better
than I.

Comment 12

[Andrew Schultz]

*** Bug 150510 has been marked as a duplicate of this bug. ***

Comment 13

[Vance Haemmerle]

Um.... I found the source for the libraries 
at http://ftp.mozilla.org/pub/mozilla/libraries/source/
and I built both the glib and gtk+ packages, but 
mozilla-bin refuses to run with this error:

20396:./mozilla-bin: /sbin/loader: Fatal Error: object libgtk-1.2.so from
liblist in ./mozilla-bin has version "9.0", which does not match the found
object: /usr/local/lib/libgtk-1.2.so (with version "2.2.0:0.0:1.0:2.0")

So, my question is... where is the binary versions of the libraries
which are compatible with the mozilla-bin distributed?  And why the
version dependence?  Seems kinda useless to distribute binary versions
if you have to get the source for mozilla and recompile it.  Why not
just distribute the binary versions of the libraries like you used to
pre-0.9.4?

Comment 14

[Vance Haemmerle]

http://ftp.mozilla.org/pub/mozilla/libraries/source/

has an old version of the gtk and glib libraries.
The tru64 binary needs 1.2.10 of each, available
at ftp.gtk.org.  /sbin/loader no longer has a version
mismatch when this version is used.  However, it 
doesn't seem to do anything either... -version and
-help puts out the correct text, but the program
doesn't seem to do anything else.

Comment 15

[Vance Haemmerle]

I sucessfully got Mozilla 1.0 running.
I had to rerun the script that registers
its components.

Comment 16

[Andrew Schultz]

http://www.mozilla.org/unix/tru64.html has some info, although it is slightly
dated (glib/gtk v1.2.8)

I'm pretty sure the last nightly I tried had a README file, but the 1.0 release
does not seem to have one.

FWIW: I have glib/gtk 1.2.10, but it still complains about
__cxx_call_static_dtors as un unresolved symbol. (my system does have libcxx.so
if that's relevant).

Comment 17

[Sim Alam]

This bug should probably be closed now.