Closed
Bug 83544
Opened 23 years ago
Closed 23 years ago
redundant global functions in smime & vcard
Categories
(MailNews Core :: MIME, defect)
MailNews Core
MIME
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.6
People
(Reporter: cls, Assigned: netscape)
References
Details
(Whiteboard: have fix)
Attachments
(6 files, 3 obsolete files)
4.65 KB,
patch
|
bugzilla
:
review+
|
Details | Diff | Splinter Review |
19.03 KB,
patch
|
bugzilla
:
review+
|
Details | Diff | Splinter Review |
19.18 KB,
application/octet-stream
|
bugzilla
:
review+
|
Details |
120.78 KB,
application/octet-stream
|
bugzilla
:
review+
|
Details |
137.04 KB,
application/octet-stream
|
bugzilla
:
review+
|
Details |
118.76 KB,
application/octet-stream
|
bugzilla
:
review+
|
Details |
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
QA Contact: esther → stephend
Comment 1•23 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
Closed: 23 years ago
Resolution: --- → FIXED
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•23 years ago
|
||
Ok, sorry for jumping the gun.
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Comment 4•23 years ago
|
||
How is this a perf issue - symbol fixup when loading ?
Comment 5•23 years ago
|
||
I think this was blocking the static build at one point.
Comment 6•23 years ago
|
||
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!
Comment 7•23 years ago
|
||
Updated•23 years ago
|
Whiteboard: have fix
Assignee | ||
Comment 8•23 years ago
|
||
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
Assignee | ||
Comment 9•23 years ago
|
||
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 .
Assignee | ||
Comment 10•23 years ago
|
||
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
Assignee | ||
Comment 13•23 years ago
|
||
Assignee | ||
Comment 14•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Attachment #55216 -
Attachment is obsolete: true
Assignee | ||
Updated•23 years ago
|
Attachment #55213 -
Attachment is obsolete: true
Assignee | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
Assignee | ||
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
Christopher, can I reassign this bug to you as you do all the work?
Assignee | ||
Comment 19•23 years ago
|
||
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 20•23 years ago
|
||
Comment on attachment 56288 [details] [diff] [review] Updated with win32 changes R=ducarroz
Attachment #56288 -
Flags: review+
Comment 21•23 years ago
|
||
Comment on attachment 55214 [details] [diff] [review] Changes to nsMimeContentHandlerType class (files are actually in glue/ now) R=ducarroz
Attachment #55214 -
Flags: review+
Comment 22•23 years ago
|
||
Comment on attachment 56292 [details]
vcard.mcp
R=ducarroz
Attachment #56292 -
Flags: review+
Comment 23•23 years ago
|
||
Comment on attachment 56291 [details]
smime.mcp
R=ducarroz
Attachment #56291 -
Flags: review+
Comment 24•23 years ago
|
||
Comment on attachment 56290 [details]
calendar.mcp
R=ducarroz
Attachment #56290 -
Flags: review+
Comment 25•23 years ago
|
||
Comment on attachment 56289 [details]
Updated glue.zip with mac+win32 changes
R=ducarroz
Attachment #56289 -
Flags: review+
Comment 26•23 years ago
|
||
rs=waterson
Assignee | ||
Comment 27•23 years ago
|
||
Checked in.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•