85536 - duplicate symbols in import modules

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Chris Waterson]

There are duplicate symbols in the mail/news import modules that are preventing
us from linking the mail/news meta-component on Win32. I'll produce a list of
the duplciates shortly.

Comment 1

[Chris Waterson]

Attachment: duplicate symbols building mail.dll on STATIC_BUILD_20010612_BRANCH

Comment 2

[Chris Waterson]

Okay, I've fixed all of them but SimpleBuffer, which as class that was
copy-and-pasted into both nsOutlookCompose.[h|cpp] and nsEudoraCompose.[h|cpp].
I am _not_ going to fix that; tonyr, your fingerprints are all over this. Why
didn't you factor that stuff into a utility class? Or at worst, a class with all
inline methods? (Grumble grumble.)

Comment 3

[Chris Waterson]

Attachment: uniquify duplicate names in import code

Comment 4

[Chris Waterson]

Attachment: smart-assed fix for SimpleBuffer, too

Comment 5

[Chris Waterson]

tonyr, can you r=? sspitzer, sr=?

Comment 6

[(not reading, please use [e-mail] instead)]

so much duplicated code under mozilla/mailnews/import...that's the real cause.
but there's another bug about fixing that.

is the static build win32 only?  are we going to do a mac static build?  there
are some .cpp files only built on the mac (and some only built on win32.)  

there might be some more duplicate symbols on the mac.

thanks for doing this, chris.  your changes all look safe.  cc'ing nbaca (who
does import QA)

r/sr=sspitzer

Comment 7

[Chris Waterson]

> is the static build win32 only?  are we going to do a mac static build?
> there are some .cpp files only built on the mac (and some only built on win32.)  

The static build is XP, but so far we've only gotten Linux and Win32 off the
ground. I'll letcha know about Mac when we run into problems there. :-)

Comment 8

[Chris Waterson]

I'll take the bug and land the fix with the STATIC_BUILD branch.

Comment 9

[David :Bienvenu]

:-) r/sr = bienvenu. But. Seems to me that the import modules would be a great
candidate not to be part of the static build since they are so rarely used and I
hope wouldn't be loaded by default. Is it all or nothing?

Comment 10

[Chris Waterson]

They're built into mail.dll, which loads ``everything mail''. I don't really
care if they're in that DLL, or in ``mail-import.dll'', or each packaged
individually like they are now. (And FWIW, windows won't page in -- i.e., touch
-- unused code, or even create space for the pages in the swap file, so long as
we ship a properly rebase'd DLL.)

Comment 11

[Rajiv Dayal]

i am currently adding a feature to import Comm4x address books to N6. The target 
milestone for me is 0.9.2. Also I am modifying some of the base interfaces 
nsIImportAddressBooks and nsIImportGeneric for this. So please let me know 
before you checkin the code for this as this may impact what i am doing or 
vice-versa. Adding myself to the CC list. 

Comment 12

[Chris Waterson]

Fix checked in with STATIC_BUILD_20010612_BRANCH landing.

Comment 13

[[e-mail] (gone - use [e-mail] instead)]

Verified FIXED via code verification, using LXR:

Module followed by Revision Number:
------------------------------------------------
nsEudoraCompose.cpp 1.23 (waterson) 1.24 (cathleen)
nsEudoraImport.cpp 1.18
nsOEAddressIterator.cpp 1.11
nsOEImport.cpp 1.19
nsOutlookCompose.cpp 1.17
nsOutlookImport.cpp 1.16
nsOutlookMail.cpp 1.13
nsImportMail.cpp 1.31
nsEudoraCompose.h 1.7
nsEudoraMailbox.cpp 1.10
nsEudoraMailbox.h 1.5
nsEudoraWin32.cpp 1.19
nsOutlookCompose.h 1.4

If there are any outstanding issues, please file those seperately, thanks.