Closed Bug 236331 Opened 22 years ago Closed 20 years ago

SVG compile error in nsSVGLibartGlyphMetricsFT.cpp due to string API changes

Categories

(Core :: SVG, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: lorenzo, Assigned: alex)

References

Details

Attachments

(1 file)

I tried to build an SVG-enabled firefox on Linux using libart but it fails when trying compiling nsSVGLibartGlyphMetricsFT.cpp: nsSVGLibartGlyphMetricsFT.cpp: In function `void NS_InitSVGLibartGlyphMetricsFTGlobals()': nsSVGLibartGlyphMetricsFT.cpp:158: no matching function for call to `nsDataHashtable<nsStringHashKey,nsDependentString *>::Put (const nsString &, NS_ConvertASCIItoUTF16 *)' ../../../../../dist/include/xpcom/nsBaseHashtable.h:145: candidates are: PRBool nsBaseHashtable<nsStringHashKey,nsDependentString *,nsDependentString *>::Put(const nsAString &, nsDependentString *) nsSVGLibartGlyphMetricsFT.cpp:162: no matching function for call to `nsDataHashtable<nsStringHashKey,nsDependentString *>::Put (const nsString &, NS_ConvertASCIItoUTF16 *)' ../../../../../dist/include/xpcom/nsBaseHashtable.h:145: candidates are: PRBool nsBaseHashtable<nsStringHashKey,nsDependentString *,nsDependentString *>::Put(const nsAString &, nsDependentString *) nsSVGLibartGlyphMetricsFT.cpp:166: no matching function for call to `nsDataHashtable<nsStringHashKey,nsDependentString *>::Put (const nsString &, NS_ConvertASCIItoUTF16 *)' ../../../../../dist/include/xpcom/nsBaseHashtable.h:145: candidates are: PRBool nsBaseHashtable<nsStringHashKey,nsDependentString *,nsDependentString *>::Put(const nsAString &, nsDependentString *) gmake[2]: *** [nsSVGLibartGlyphMetricsFT.o] Error 1 http://lxr.mozilla.org/seamonkey/source/layout/svg/renderer/src/libart/nsSVGLibartGlyphMetricsFT.cpp#156 The problem is lines like these: static NS_NAMED_LITERAL_STRING(arial, "arial"); nsSVGLibartGlyphMetricsFT::sFontAliases.Put(NS_LITERAL_STRING("helvetica"), &arial); which makes me think that the problems are due to the recent string changes. Changing: static NS_NAMED_LITERAL_STRING(arial, "arial"); to static nsDependentString arial(NS_LITERAL_STRING("arial")); fixes the problem for me, but I'm pretty sure this is not the right way to do it.
This works for me. Are you sure your checkout is up-to-date?
Yes, I just refreshed my tree now. Maybe it's because I'm using GCC 2.95?
Darin, is there something wrong with using static strings like we do here?
So static string are indeed not allowed any more :-( news://news.mozilla.org:119/mailman.1077677041.13244.mozilla-xpcom@mozilla.org
nsDependentString arial(NS_LITERAL_STRING("arial")); is anyways totally invalid since the NS_LITERAL_STRING will expand to NS_ConvertASCIItoUTF16 if the compiler cannot generate double byte string literals. see my newsgroup posting for suggested alternatives to static literal strings.
*** Bug 247641 has been marked as a duplicate of this bug. ***
Attached patch patch — — Splinter Review
untested patch, not sure if it's the right fixed but it does avoid using NS_NAMED_LITERAL_STRING and NS_LITERAL_STRING.
this is possibly the same as bug 271174
*** Bug 247641 has been marked as a duplicate of this bug. ***
Marking wontfix. We have no plans to continue development of the libart backend.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: