80613 - META Mozilla should have proper versioning for all binaries on all platforms

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect)

Description

[Greg Smith]

I just installed mozilla 0.9 using the mozilla-installer (I had previously been
using the mozilla 0.8.1 that came with Ximian Gnome). The installer actually
starts Mozilla up just fine and I was merrily installing themes. However, after
exiting the instance of mozilla that was brought by the installer, and
attempting to start it from the command line I get:

(command prompt) > mozilla
Registering plugin 0 for: "*","All types",".*"
Registering plugin 0 for: "*","All types",".*"
**************************************************
nsNativeComponentLoader:
GetFactory(/usr/lib/mozilla-0.8.1/components/libmsgnews.so) Load FAILED with
error: /usr/lib/libnspr4.so: undefined symbol: NSGetFactory
**************************************************
XML Error in file
'file:///home/gregs/.mozilla/gregs-1/ydn3jhzy.slt/localstore.rdf', Line Number:
74, Col Number: 3, Description: unclosed token
Source Line:   <RDF:Descriptio
Segmentation fault

I tried installing again using mozilla-installer. It installed and started up
the program just fine. But again, trying to restart mozilla from the command
line created the same problem listed above.

BTW, I uninstalled all of my 0.8.1 mozilla rpms, except mozilla.0.8.1-ximian.13
which was required by nautilus.

Comment 1

[timeless]

what are the dates for mozilla-bin, libmsgnews.so and libnspr4.so? And where 
did you install mozilla?  My guess is that you managed to mix the old mozilla 
NSPR w/ the new mozilla build. editing your path or something would probably 
fix it...

This is quite possibly not our bug, but sending to build config because they 
understand the issues..

Comment 2

[cls]

Ximian?  Bouncing to Myth.

Comment 3

[Frank Belew]

This seems to be a clear case on why the versioning scheme on the libraries
provided by mozilla/netscape is insufficient.

I separated out libnspr since it is required by libnss, and anything that wants
to use it. 

I'm not sure if it has been fixed yet, but last I looked, nspr had a different
symbol table entirely if you --enable-debug.

I guess blizzard should obsolete libnspr in his package, or split it out as well
until we can get a better solution.

(adding blizzard to cc:)

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I don't think this is a libnspr problem, necessarily; the error reporting there
can be decieving, and we certainly don't expect to find NSGetFactory in libnspr.
 (libnspr hasn't changed in a while, I don't think.)

Looks like you're trying to load the 0.8.1 library into your 0.9 build.  Maybe
you have an out-of-date component.reg?

Comment 5

[Frank Belew]

Ahh, so maybe its due to the lack of versioning on the mozilla libs themselves?

/usr/lib/libcmt.so
/usr/lib/libgkgfx.so
/usr/lib/libgtkembedmoz.so
/usr/lib/libgtksuperwin.so
/usr/lib/libgtkxtbin.so
/usr/lib/libjsdom.so
/usr/lib/libjsj.so
/usr/lib/libmozjs.so
/usr/lib/libmsgbaseutil.so
/usr/lib/libprotocol.so
/usr/lib/libxpcom.so
/usr/lib/libxpistub.so

Are all versionless, but still need to be linked against for embedding.
Since none are pure components afaik, they do belong in a standard lib location
instead of a private one. On my machine, Nightles from tarballs still work fine
due to LD_LIBRARY_CONFIG

Comment 6

[Ken Snider]

Confirming and modifying Summary

Comment 7

[Brian 'netdragon' Bober]

Please take a look at bug 23560. It is about versioning on Win32.

Comment 8

[gekacheka]

bug 53727 discusses so versioning mozilla libs.

Comment 9

[Brian 'netdragon' Bober]

Changing summary, removing obsolete keyword: "mozilla1.0+". Making it a meta bug
for versioning bugs that need fixing prior to, hopefully, Mozilla 2.0.

Bug 23560 introduces files called "module.ver". Information could be added in
this for every platform. For instance, one used on windows is:
WIN32_MODULE_COMMENT.

You can preface Linux-specific versioning as
LINUX_SO_COMMENT (I don't know how Linux versioning works) if its possible to
build the versioning information at the same time as the libraries. I don't know
the specifics of that, but anyway, bug 53727 is about .so versioning on Unix.

What about Macs?

WIN32: http://bugzilla.mozilla.org/show_bug.cgi?id=50627
Linux: http://bugzilla.mozilla.org/show_bug.cgi?id=53727
Mozilla-win32-installer.exe: http://bugzilla.mozilla.org/show_bug.cgi?id=136684
GRE: http://bugzilla.mozilla.org/show_bug.cgi?id=180383
More to come...

Comment 10

[Brian 'netdragon' Bober]

Contain BUILD ID in MacOS: http://bugzilla.mozilla.org/show_bug.cgi?id=147456
Unhardcode versions: http://bugzilla.mozilla.org/show_bug.cgi?id=169074
NSS: http://bugzilla.mozilla.org/show_bug.cgi?id=84390

Not only is not versioning hard for packaging, but its unprofessional. That is a
list of the bugs that need to be fixed. Feel free to add any.

Comment 11

[Frank Belew]

Since this is a meta bug, it is no longer a purely ximian problem, reassigning
to default owner/qa.

Comment 12

[hacker formerly known as [e-mail]]

You morph the bug, you own it.

Comment 13

[Simon Paquet [:sipaq]]

Definitely not a blocker.

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 15

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 17

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 18

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 19

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 20

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 21

[Robert Kaiser]

There are no plans for working on this for SeaMonkey specifically, and additionally, it's also unclear what this is about. Please file a new bug in the appropriate component if you still have and issue.