Closed Bug 86254 Opened 19 years ago Closed 19 years ago

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

Categories

(SeaMonkey :: Build Config, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED
mozilla0.9.3

People

(Reporter: cls, Assigned: cls)

References

Details

(Whiteboard: ready for checkin?)

Attachments

(2 files)

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 .
Blocks: 46775
Keywords: mozilla0.9.2
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
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.
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.
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.
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
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
sr=waterson
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
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?
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.
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
Whiteboard: critical for 0.9.2; ready for checkin? → ready for checkin?
not a blocker for 0.9.2 so setting 0.9.3
Priority: -- → P3
Target Milestone: --- → mozilla0.9.3
Changes have been checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.