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 .
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
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
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.