redundant global functions in smime & vcard

VERIFIED FIXED in mozilla0.9.6

Status

MailNews Core
MIME
VERIFIED FIXED
17 years ago
9 years ago

People

(Reporter: cls, Assigned: hacker formerly known as seawood@netscape.com)

Tracking

Trunk
mozilla0.9.6

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: have fix)

Attachments

(6 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
In attempting to link all of the mail components into a meta component (bug
46775), I ran across a problem with the same functions being defined/declared
extern "C" in both vcard & smime. Similar to bug 76788 I think.

../../dist/lib/components/libsmime.a(mimexpcom.o): In function
`COM_GetmimeInlineTextClass':
mimexpcom.o(.text+0x0): multiple definition of `COM_GetmimeInlineTextClass'
../../dist/lib/components/libvcard.a(mimexpcom.o)(.text+0x0): first defined here


../../dist/lib/components/libsmime.a(nsSMIMEStub.o): In function
`MIME_GetContentType':
nsSMIMEStub.o(.text+0x0): multiple definition of `MIME_GetContentType'
../../dist/lib/components/libvcard.a(mimevcrd.o)(.text+0x0): first defined here

etc
(Reporter)

Updated

17 years ago
Blocks: 46775
QA Contact: esther → stephend

Comment 1

17 years ago
This was fixed when we landed the STATIC_BUILD_20010612_BRANCH, no? (If not
before?) cls, re-open the bug if I'm wrong...
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
(Reporter)

Comment 2

17 years ago
This was never fixed on the branch.   All I did was reomve smime from the list
of components to be included in the mail meta-component.   I'm guessing the
reason that we're not seeing this problem in the completely static build is that
those functions in smime and/or vcard are never directly referenced so they are
stripped out in the final link.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 3

17 years ago
Ok, sorry for jumping the gun.

Updated

16 years ago
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.6

Comment 4

16 years ago
How is this a perf issue - symbol fixup when loading ?

Comment 5

16 years ago
I think this was blocking the static build at one point.
Every mime cthandlers (calendar, cvard, smime) include a file name
mimexpcom.cpp. They are all the same therefore, in the static build you need to
make sure you include only one of them!


Created attachment 54922 [details] [diff] [review]
proposed fix, v1

Updated

16 years ago
Whiteboard: have fix
Comment on attachment 54922 [details] [diff] [review]
proposed fix, v1

It didn't quite work as the nsMimeContentTypeHandler.* files are duplicated as well.
Attachment #54922 - Attachment is obsolete: true
With cthandlers/*/mimexpcom.* & cthandlers/*/nsMimeContentTypeHandler.* being
exact duplicates, I decided to fork them off into a static glue lib that would
be linked into each of the handlers in a dynamic build but only into the final
link of a static build.  I ran into a slight problem because each of the 3
cthandlers uses the single nsMimeContentTypeHandler class as their registered
module.  So I had to hack the factories & nsMimeContentTypeHandler to allow the
factories to pass in mimetypes & a callback function to distinguish between the
cthandlers.  Surprisingly, it even worked.

Here's a patch against cthandlers/ , a separate patch of the changes made to
nsMimeContentTypeHandler and a zip of cthandlers/glue .

Created attachment 55213 [details] [diff] [review]
Modify cthandler factories to use modified nsMimeContentTypeHandler class
Created attachment 55214 [details] [diff] [review]
Changes to nsMimeContentHandlerType class (files are actually in glue/ now)
Created attachment 55216 [details]
zip of glue/
Created attachment 56288 [details] [diff] [review]
Updated with win32 changes
Created attachment 56289 [details]
Updated glue.zip with mac+win32 changes
Attachment #55216 - Attachment is obsolete: true
Attachment #55213 - Attachment is obsolete: true
Created attachment 56290 [details]
calendar.mcp
Created attachment 56291 [details]
smime.mcp
Created attachment 56292 [details]
vcard.mcp
Christopher, can I reassign this bug to you as you do all the work?
Sure, I'll take it.  But I still need a review / verification of the patches
since this isn't exactly my area of expertise. :)
Assignee: ducarroz → seawood
Status: ASSIGNED → NEW
Comment on attachment 56288 [details] [diff] [review]
Updated with win32 changes

R=ducarroz
Attachment #56288 - Flags: review+
Comment on attachment 55214 [details] [diff] [review]
Changes to nsMimeContentHandlerType class (files are actually in glue/ now)

R=ducarroz
Attachment #55214 - Flags: review+
Comment on attachment 56292 [details]
vcard.mcp

R=ducarroz
Attachment #56292 - Flags: review+
Comment on attachment 56291 [details]
smime.mcp

R=ducarroz
Attachment #56291 - Flags: review+
Comment on attachment 56290 [details]
calendar.mcp

R=ducarroz
Attachment #56290 - Flags: review+
Comment on attachment 56289 [details]
Updated glue.zip with mac+win32 changes

R=ducarroz
Attachment #56289 - Flags: review+

Comment 26

16 years ago
rs=waterson
Checked in.
Status: NEW → RESOLVED
Last Resolved: 17 years ago16 years ago
Resolution: --- → FIXED
By verifying this, I'm assuming that if you can build successfully (which I
have) then it's just something to verify via code inspection (using LXR/tree).

If I'm wrong, please re-open and correct me.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.