53727 - none of the libraries created contain soversions

Status: RESOLVED WONTFIX

(SeaMonkey :: Build Config, defect, P3)

Description

[Frank Belew]

None of the libraries created by the mozilla build that are intended to be
used by other applications have soversions, this causes problems on unix.
Especially if you change the API without changing the soversion.

Comment 1

[Stuart Parmenter]

->cls

I agree and think we should do library versioning on unix, but i'm not sure what
implications this has.

Comment 2

[cls]

I thought we were waiting on soversions until we actually started freezing
apis?  If this is the case, does anyone know where we can get a list of APIs
(and corresponding libs) to be frozen for PR3/moz 0.9 ?

Comment 3

[Brendan Eich [:brendan]]

Vidur can help with API freeze questions.

/be

Comment 4

[vidur (gone)]

Well...the short of it is that we're deferring freezing APIs till post-Netscape 
6/Mozilla 0.9. Not all embedding-related API changes could be done in time and 
the ones remaining will now be applied to the trunk.

The API review meetings will start again shortly and we'll delve back into 
freezing part or all of XPCOM. This means that we (actually developers who were 
hoping for a freeze) are SOL with respect to Netscape 6. By early next year 
(most probably in time for Mozilla 1.0) we'll have a complete set of frozen 
XPCOM and embedding interfaces.
 

Comment 5

[cls]

As I just posted in the "Freezing Embedding interfaces" thread in m.xpcom, I
think the only truly XP way of doing shared library versioning is to follow
nspr's example of including the major number (should be major & minor though) as
part of the library name.  If XP file names are not a concern, then sonames
should work fine on the platforms that support them. 

The important piece that needs to be acknowledged by owners of the libs we want
to start versioning is the importance of the frozen APIs and what will be
expected once we start versioning the libraries.  I ran across this paper which
seems to sufficiently define what library versioning means (and should mean to us):

http://www.usenix.org/publications/library/proceedings/als2000/full_papers/browndavid/browndavid_html/#pgfId-998540

Right now, I guess I'm really only concerned about versioning the non-component
libraries.  Components will require an additional level of versioning to be
handled by the component manager so I'm not sure what additional benefits soname
versioning will give us since we load the libraries directly.

Comment 6

[Doug Turner (:dougt)]

I am not sure exactly if this will be fixed prior to mozilla 1.0. 

Comment 7

[Brendan Eich [:brendan]]

dougt: I'm here to say, on behalf of mozilla.org, that this needs to be fixed
before any major, long-lived branch such as mozilla1.0 is cut.  Vendors and
distributors will need to identify pre-installed "system libraries" and see
whether they're up to snuff.  Or we can give up, and tell everyone to bundle his
own copy -- ask chofmann and others @netscape.com if they want that kind of
avoidable bloat on RedHat future releases that already have libxpcom.so.

cls: are there bugs on file for Windows and Mac versioning?  If not, will you do
the deeds?  Thanks,

/be

Comment 8

[Daniel (Leaf) Nunes]

there are already bugs filed for windows dll and exe versioning, but not broken
down on a component basis.

http://bugzilla.mozilla.org/show_bug.cgi?id=23560

Comment 9

[Doug Turner (:dougt)]

Brendan, et. al,  I do not think that this bug needs to be fixed for vendors and
distributors to identify what they are bundling.  What I and others (even some
non-netscape employees!) have proposed is grouping/coupling all of the mozilla
libraries and public interfaces into a single reference.  What are mozilla.org
thoughts on this?

Comment 10

[Brendan Eich [:brendan]]

dougt: please define "single reference".

What about systems (such as RH Linux) that have existing conventions for naming
and versioning system libraries?  We are not going to bend the world around our
idea of a single standard for all Mozilla APIs and libraries, even if that were
a good idea (it's not: Mozilla purveys too many distinct API sets and libs --
why should they all be dumped into one versionable bin?  My contention that we
need versioning for mozilla1.0 should not be read to mean we need *one single
version-lump* for mozilla1.0, only that mozilla1.0 bundles a bunch of versioned
things together in a coherent, long-lasting, supportable fashion).

We should take this to the newsgroups.  m.builds and m.xpcom, with followups set
to m.xpcom?  Or the underused m.platform?  Leaf, cls, please guide us.

/be

Comment 11

[Daniel (Leaf) Nunes]

brendan, this bug should really be a meta-bug, if you want individual components
to version themselves. How many components do we have that are owned strongly
with owners that are going to bother with version numbers?

NSPR and NSS, maybe, and XPCOM, if we can snooker doug into doing it :)

Do we even have a list of components that are distinct and can actually be used
from without the mozilla tree?

Comment 12

[Doug Turner (:dougt)]

Just to be clear, I am not objecting to adding versioning to libraries - we need
to do this at some point.  I am just questioning if it is needed as soon as some
suggest.  

Comment 13

[Brendan Eich [:brendan]]

dougt: don't mince words, what do you mean?  "Some suggest" might refer to me,
who thinks we should have had this per-library versioning info long ago (RH has
already shipped a Mozilla-based browser).  Exactly *when* would you want to fix
this bug, if not by mozilla1.0?  Or, what criteria do you think should apply in
deciding when to fix this bug?

/be

Comment 14

[Brendan Eich [:brendan]]

My criteria:

1.  Stable, long-lived, supported CVS branch.
2.  Useful sets of frozen, supported-till-next-super/major-version APIs.
3.  Some kind of ABI commitment (if you use compiler X on OS Y, your code can
link with version Z of our lib -- for a given Z, there may be several valid X,Y
pairs).

All of these apply to mozilla1.0, and none before it.  So I say mozilla1.0 is
the right goal.

/be

Comment 15

[cls]

Hrm.  So this bug seems to be morphing quite a bit so let me recap & refocus.

The original bug is on our lack of soversions in libraries "that are intended to
be used by other applications".  For simplicity, I'm going to interpret that as
just the libraries that mozilla directly links against.  Most of our components
(bin/components) are not ready to be frozen and I don't want to hold up 1.0
waiting for them.  (Note: people will probably come looking for our high profile
 components (gecko,necko,etc) when 1.0 is released so it wouldn't hurt to have
those frozen either). 

I think we have consensus now that using the platform native library versioning
scheme is the way to go. 

Before we can start versioning the libraries however, we need to make sure that
the APIs are frozen. Agreed?

The list of "public" libraries are:

libgkgfx
libmozjs
libjsj
libxpcom
libnspr4
libplc4
libplds4


NSPR (nspr,plc,plds) is already frozen.  I'm not sure about the states of gfx,
js & liveconnect (jsj). xpcom is in the process of being frozen.

Having these libraries versioned should be mozilla1.0 criteria since mozilla1.0
is greatly perceived as the "hey, I'm stable; come use me!" release.  


 

Comment 16

[Doug Turner (:dougt)]

I think that we should fix this bug after we have a defined set of APIs which
can and will be supported by a stated libary version number.  Anything prior to
this is  IMO pointless.

Comment 17

[Brendan Eich [:brendan]]

It's not pointless to figure out *how* our build system will need to be tweaked
to do the right version-stamping.  The people working on build-fu and the people
working on API freezes form almost disjoint sets.

/be

Comment 18

[rpotts (gone)]

I think that this bug is somewhat orthoganal to API freezing.  

I agree with leaf that this should really be a meta bug that tracks the adoption
of version-info in *each* mozilla DLL.

To some extent this is really a DLL packaging issue more than an API freezing
issue...

I totally agree that this work needs to be done for mozilla 1.0, but i consider
it secondary to actually defining the frozen APIs for mozilla 1.0

-- rick

Comment 19

[Doug Turner (:dougt)]

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

Comment 20

[hacker formerly known as [e-mail]]

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

Comment 21

[Henrik Gemal]

this bug is also for version resources on the windows platform. See bug 50627.
And it's not only in GTK widgets. It's on all .dll and *.exe files on the
windows platform.

Comment 22

[Braden]

I realize they have already been removed from the discussion on the basis of
expedience, but I suggest that this bug should not apply to component modules at
all. Component modules are not linked against, and versioning them can (and
should) be taken care of using contractIDs.

Comment 23

[hacker formerly known as [e-mail]]

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

Comment 24

[Juan José Mata]

Moving milestone out to future since we've obviously missed the 1.1beta.

Comment 25

[R.K.Aa.]

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

Comment 26

[Juan José Mata]

EDT triage on 1/10: removing topembed+ keyword.

Comment 27

[Judson Valeski]

juan meant to minus this one earlier.

Comment 28

[:deanis74]

From bug 50627, "See also bug 23560 which set the groundwork that can be
extended to the rest of Mozilla by adding module.ver files throughout."

Comment 29

[cls]

Mass reassign to default build config owner

Comment 30

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 31

[Don Armstrong]

What's the current status of this bug?

We seem to keep running into issues with these libraries when they break API
compatibility with things like galeon, and it would be nice to fix it correctly.
See debian bug http://bugs.debian.org/265626

Comment 32

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 33

[Benjamin Smedberg]

WONTFIX. Because of interdependencies and support files, the correct way to link against a particular version of gecko is to use the standalone glue.