Closed Bug 94221 Opened 23 years ago Closed 15 years ago

Lack of code sharing in i18n converters hinders static build

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 157993

People

(Reporter: sfraser_bugs, Assigned: nhottanscp)

References

Details

Attachments

(1 file)

Many of the i18n converts duplicate common code, without sharing the same source files. For example, the following C++ classes appear in many different files in the tree: nsBasicEncoder nsEncoderSupport nsBasicDecoderSupport nsBufferDecoderSupport nsTableDecoderSupport nsMultiTableDecoderSupport nsOneByteDecoderSupport The problem with this is that since this code is duplicated in many different files, that code may have diverged. When we link the static build, the linker strips out all but one copy of the source, so, if the source has diverged, some calls may end up in a different implementation. The least that needs to happen here is that the common code is factored out into unique source files (so we know the code is identical across converters). Ideally, the code should be shared between converters by moving it into a shared, non-component DLL.
This affects all platforms.
OS: Mac System 8.5 → All
Hardware: Macintosh → All
Attached file Static build link warnings (deleted) —
The attached static build link warnings show how many of these duplicate symbol warnings there are from these classes.
nsTableEncoderSupport and nsMultiTableEncoderSupport should also be in the list.
Blocks: 81373
not quite sure how to address this issue yet.
Status: NEW → ASSIGNED
not quite sure how to address this issue yet. Is there a compilation flag we can test against static linking build?
Not yet. The Mac static build will land in the next week or so, and then you'll be able to set the static_build option.
reassigning per ftang's request
Assignee: ftang → jbetak
Status: ASSIGNED → NEW
accepting and targeting post-0.9.4. Will clarify with ftang, whether this is acceptable...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Target Milestone: mozilla0.9.5 → mozilla0.9.6
>Ideally, the code should be shared between converters by moving it into a shared, >non-component DLL. ftang do you agree with such a change? If not, I'd try to consolidate the duplicate code into unique source files - the alternative solution suggested by sfraser.
looks like this won't happen in M096 time frame. Sfraser - how urgent is this, could you also possibly give me a hand with some intial redesign ideas?
Target Milestone: mozilla0.9.6 → mozilla0.9.7
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
give it to nhotta nhotta- can you coach rchen to do this ?
Assignee: ftang → nhotta
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → ---
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
Keywords: mozilla1.0+
Target Milestone: mozilla1.2alpha → ---
Changing QA contact to bobj for now. Bob, please re-assign further as you see is appropriate.
QA Contact: andreasb → bobj
QA Contact: bobj → i18n
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: