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

RESOLVED FIXED in mozilla0.9.3

Status

SeaMonkey
Build Config
P3
normal
RESOLVED FIXED
17 years ago
14 years ago

People

(Reporter: cls, Assigned: cls)

Tracking

Trunk
mozilla0.9.3
x86
Linux

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: ready for checkin?)

Attachments

(2 attachments)

(Assignee)

Description

17 years ago
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 .
(Assignee)

Updated

17 years ago
Blocks: 46775
Keywords: mozilla0.9.2
(Assignee)

Comment 1

17 years ago
Created attachment 38777 [details] [diff] [review]
Initial patch for unix

Comment 2

17 years ago
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.
Status: NEW → ASSIGNED
(Assignee)

Comment 3

17 years ago
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.
(Assignee)

Comment 4

17 years ago
Created attachment 39161 [details] [diff] [review]
Update nss lib names used by psm

Comment 5

17 years ago
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.
(Assignee)

Comment 6

17 years ago
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

17 years ago
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?
it is probably easier to change mozilla than nss.

cc'ing ducarroz, since he is the owner of mime.
It's fine with me to rename mozilla/mailnews/mime/cthandlers/smimestub library
(Assignee)

Comment 10

17 years ago
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
R=ducarroz

Comment 12

17 years ago
sr=waterson

Comment 13

17 years ago
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?
OS/2 might still be 8.3

in this case, just be safe and do 8.3

Comment 15

17 years ago
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.

As long as you make it an 8.3 name a=blizzard on behalf of drivers for 0.9.2.
Whiteboard: critical for 0.9.2
What's the status on getting this checked in?
Whiteboard: critical for 0.9.2 → critical for 0.9.2; ready for checkin?

Comment 18

17 years ago
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

17 years ago
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.
Assignee: wtc → cls
Status: ASSIGNED → NEW
Component: Libraries → Build Config
Product: NSS → Browser
QA Contact: sonmi → granrose
Summary: static nss libs have wrong name → Rename the smimestub library (was: static nss libs have wrong name)
Version: 3.2.2 → other

Updated

17 years ago
Whiteboard: critical for 0.9.2; ready for checkin? → ready for checkin?

Comment 20

17 years ago
not a blocker for 0.9.2 so setting 0.9.3
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
(Assignee)

Comment 21

17 years ago
Changes have been checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.