Closed Bug 5832 Opened 26 years ago Closed 25 years ago

ender component not loadable due to unresolved symbol

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: tor, Assigned: mozeditor)

Details

editor/base/nsHTMLEditRules.cpp defines "nbsp" in the following manner: const unsigned char nbsp = nbsp; As nbsp is never defined in any other file (according to LXR and a quick look myself), this creates an unresolved reference in the libender.so component. This causes the component load to fail: nsComponentManager: Load(/tmp/mozilla/dist/bin/components/libender.so) FAILED with error: ld.so.1: ./viewer: fatal: relocation error: file /tmp/mozilla/dist/bin/components/libender.so: symbol nbsp: referenced symbol not found Setting nbsp to some constant value (ie. ' ') allows the component to load. I don't know what that value should be, so I'll refrain from offering a patch.
Assignee: kostello → jfrancis
Target Milestone: M5
Assigning to Joe Francis, Milestone set to M5
Status: NEW → ASSIGNED
whoah! what a typo!
Whiteboard: fix in hand
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
bad line changed to: const unsigned char nbsp = 160;
Joe, can you mark this one VERIFIED-FIXED as I have no way of verifying this one..thanks!
Status: RESOLVED → VERIFIED
marking verified...
yah, it is fixed.
Status: VERIFIED → REOPENED
reopening bug since the fix seems bad to me...
OS: Solaris → All
Hardware: Sun → All
Resolution: FIXED → ---
Whiteboard: fix in hand
Target Milestone: M5 → M7
remove status whiteboard text; change platform and OS to "ALL"; move to Milestone 7; clear the resolution cc'ed myself and ftang@netscape.com in nsHTMLEditRules.cpp, approximately line 42 now has: const unsigned char nbsp = 160; This fix seems bad to me because not only is this hard-coded in a source file which could get out of synch with other files, it is not the correct value for all platforms. I believe it should be 202 on a Macintosh. cc'ing ftang@netscape.com since he's familiar with this problem in the past and will know for sure what the correct values should be for every platform. Also, he may know if we've already fixed this in other areas of the code. The correct fix (for the editor) may be to use the character entity for nbsp:   Frank?
Status: REOPENED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → FIXED
Layout depends on nbsp being 160 on all platforms (see nsTextTransformer.cpp).
please add a comment in nsHTMLEditRules.cpp that mentions that layout requirement I still think it would be more correct to add the character entity and let layout worry about the actual character values.
can someone on editor team please verify this one and mark VERIFIED_FIXED ? thanks!
Status: RESOLVED → REOPENED
It will be better if you use const PRUnichar nbsp = 0x00A0; (note 0x00A0 == 160 in hex) insetead since PRUnichar mean Unicode and only Unicode and 0x00A0 in Unicode is always NBSP no matter what platform. Declare it as unsigned char confuse people since "unsign char" could mean ISO-8859-1, x-mac-roman, or any other encoding. reopen this Howerver, since the only usage here is
Resolution: FIXED → ---
Clearing Fixed resolution.
Target Milestone: M7 → M15
per 6/15/99 meeting, comment to be added by M15
There's a table with the mapping of entities to the values which represent them in the content tree in htmlparser/src/nsHTMLEntities.cpp, and routines to map between these values and the long-form entity descriptions in ascii, like " ". (Actually only NS_EntityToUnicode was previously defined, but I'm about to check in NS_UnicodeToEntity which was declared but not defined in nsHTMLEntities.h.) I'd recommend using this file, and making any necessary changes there so we don't have multiple copies of the entity table floating around the source; it may be that this needs to be made into a service so that it can be more easily used outside the htmlparser library.
I use PRUnichar everywhere now....
Status: REOPENED → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → FIXED
verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.