86254 - Rename the smimestub library (was: static nss libs have wrong name)

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect, P3)

Description

[cls]

The static versions of libnss & libsmime do not have the version suffix.  I
noticed this when my static build of mozilla started linking against nss'
libsmime.a instead of mozilla's libsmime.a .

Comment 1

[cls]

Attachment: Initial patch for unix

Comment 2

[Wan-Teh Chang]

This is intentional.  Only the shared libraries can
be replaced at run time and hence need to contain
versioning information.

One thing I don't understand is why the regular
non-static build of mozilla isn't broken.  The
two libsmime.a's are both installed in dist/lib,
so one would override the other.

The only way to fix this is to rename one of the
libsmime.a's.

Comment 3

[cls]

The non-static build isn't broken because we don't actually attempt to link
against mailnews' copy of libsmime in a non-static build.  Mailnews' libsmime is
actually installed in dist/lib/components.  Due to the way things are set up, we
cannot just put -L$(DIST)/lib/components before -L$(DIST)/lib in EXTRA_DSO_LDOPTS.  

Having a static library not use the same basename as the shared library doesn't
make any sense regardless of whether or not it can be replaced at runtime, where
basename is defined as everything but the suffix.  If the static library isn't
meant to be used by the end developer at all, then it shouldn't be built.

Comment 4

[cls]

Attachment: Update nss lib names used by psm

Comment 5

[Wan-Teh Chang]

Our library naming convention is irrelevant to this bug.

The issue at hand is simple.  We have a library name conflict.
They are installed in two different directories, so there is
a way to tell them apart, but that's more work than you want
to do and will break if we ever want to install them in the
same directory.  So one of us need to change our library name.
I want you to change yours, and you want me to change mine.
But changing the library name does not require changing the
library naming convention.

To be honest, it is much easier to change the libsmime.a in
mozilla/mailnews/mime/cthandlers/smimestub.  I'll be happy
to negotiate with the owner of that module.

Comment 6

[cls]

Actually, your naming convention *is* the problem here.  You are doing something
that's non-standard as far as shared & static libraries go.  On every platform
that I'm aware of, the convention is that shared & static libraries for the same
library have the *same* basename.  If you hadn't decided that this convention
didn't apply to you, we wouldn't be having this conversation.  The supposed ease
of renaming is irrelevant to this bug as we're supposed to be doing the right
thing.  The right thing is to stick to the standard convention for your
libraries since people and projects other than yours want to use them.

Comment 7

[Chris Waterson]

Yeah, this blocks our ability to do a static build. wtc, I know that consistency
is the hobgoblin of little minds like ours, but it seems like something we ought
do. Is this hard for you to change or something?

Comment 8

[(not reading, please use [e-mail] instead)]

it is probably easier to change mozilla than nss.

cc'ing ducarroz, since he is the owner of mime.

Comment 9

[Jean-Francois Ducarroz]

It's fine with me to rename mozilla/mailnews/mime/cthandlers/smimestub library

Comment 10

[cls]

Index: mailnews/mime/cthandlers/smimestub/Makefile.in
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/cthandlers/smimestub/Makefile.in,v
retrieving revision 1.8
diff -u -r1.8 Makefile.in
--- Makefile.in 2001/06/20 20:21:38     1.8
+++ Makefile.in 2001/06/20 23:56:53
@@ -27,7 +27,7 @@
 include $(DEPTH)/config/autoconf.mk
 
 MODULE         = smime
-LIBRARY_NAME   = smime
+LIBRARY_NAME   = smimestub
 META_COMPONENT = mail
 EXPORT_LIBRARY = 1
 IS_COMPONENT   = 1

Comment 11

[Jean-Francois Ducarroz]

R=ducarroz

Comment 12

[Chris Waterson]

sr=waterson

Comment 13

[Wan-Teh Chang]

You might want to make that "smimestb" to be 8.3 compliant.
Is 8.3 still a requirement on any of the platforms we need
to support?

Comment 14

[(not reading, please use [e-mail] instead)]

OS/2 might still be 8.3

in this case, just be safe and do 8.3

Comment 15

[Mike Kaply [:mkaply]]

We only need 8.3 on DLL (shared lib) names, and we have a special define for 
those.

You can make the Unix name long and then set SHORT_LIBNAME to be the 8.3 name.

See http://lxr.mozilla.org/seamonkey/source/uriloader/build/Makefile.in#32 for 
an example.

Comment 16

[Christopher Blizzard (:blizzard)]

As long as you make it an 8.3 name a=blizzard on behalf of drivers for 0.9.2.

Comment 17

[Christopher Blizzard (:blizzard)]

What's the status on getting this checked in?

Comment 18

[Wan-Teh Chang]

I didn't check in the new patch (changing the smimestub library
name).  I didn't realize I was expected to commit the patch.  I
can check it in on the trunk and the MOZILLA_0_9_2_BRANCH when
the tree re-opens for checkins.

Comment 19

[Wan-Teh Chang]

I am changing the product:component to Browser:Build Config.

I thought I would just commit cls's patch for smimestub/Makefile.in.
Then I noticed that there is smimestub/Makefile.win, and I am not
sure whether that needs to be changed too.

Comment 20

[Jon Granrose]

not a blocker for 0.9.2 so setting 0.9.3

Comment 21

[cls]

Changes have been checked in.