Closed Bug 530018 Opened 12 years ago Closed 11 years ago
_Decompile To String Undefined symbol
/opt/SUNWspro/bin/CC -o js -I/usr/X11/include -xlibmieee -xbuiltin=%all -features=tmplife -norunpath -mt -DDEBUG -D_DEBUG -DDEBUG_ginn -DTRACING -g -features=extensions -D__FUNCTION__=__func__ js.o -L../../../dist/lib -ljemalloc -lpthread -M /usr/lib/ld/map.noexstk -xildoff -z lazyload -z combreloc -z ignore -R '$ORIGIN:$ORIGIN/..' -M ../../../../js/src/config/solaris_ia32.map -L../../../dist/bin -L../../../dist/lib -L/export/home/ginn/field/mozilla-central/debug/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lposix4 ../editline/libeditline.a ../libjs_static.a -lsocket -ldl -lm -lCrun -lCstd Undefined first referenced symbol in file js_DecompileToString ../libjs_static.a(jsapi.o) ld: fatal: symbol referencing errors. No output written to js
Assignee: general → ginn.chen
Status: NEW → ASSIGNED
Attachment #413537 - Flags: review?(brendan)
Comment on attachment 413537 [details] [diff] [review] patch Ducking -- doesn't jsopcode.h declare js_DecompileToString within an extern "C" block? What's the bug here, are we not following C or C++ specs? /be
Attachment #413537 - Flags: review?(brendan) → review?(jim)
This is similar to bug 429105. https://bugzilla.mozilla.org/show_bug.cgi?id=429105#c18 I think the reason is the same. JSBool (*decompiler)(JSPrinter *jp) is a c++ function pointer.
The declaration of js_DecompileToString in jsopcodes.h is extern "C". That declaration is visible to all uses. Why isn't the 'decompiler' argument taken to be a "C" function pointer?
I was reading the examples here: http://docs.sun.com/source/819-3689/Ch3.Std.html In particular, the "composer" function is declared like this: extern "C" void composer( int(*)(int) ); and is said to expect a function with C linkage. If that's the case, then it seems to me that js_DecompileToString's argument should be a function with C linkage, as well. The only functions ever passed to js_DecompileToString are js_DecompileFunctionBody and js_DecompileFunction, both of which are declared within the same extern "C" block tha js_DecompileToString is. I'm inclined to replace the function pointer argument to js_DecompileToString with a boolean flag named 'bodyonly' that simply chooses either js_DecompileFunctionBody or js_DecompileFunction.
Leon or Ginn, can you explain why the compiler doesn't seem to be treating js_DecompileToString the way the documentation I linked to suggests it should?
This is the warning message for jsopcode.cpp. "jsopcode.cpp", line 4911: Warning: function JSString*(JSContext*,const char*,JSFunction*,unsigned,int,int,int,int(*)(JSPrinter*)) overloads extern "C" JSString*(JSContext*,const char*,JSFunction*,unsigned,int,int,int,extern "C" int(*)(JSPrinter*)) because of different language linkages. For js_DecompileToString function in jsopcode.h, both js_DecompileToString and JSBool (*decompiler)(JSPrinter *jp) are inside extern "C" and have c linkage. But in jsopcode.cpp, the JSBool (*decompiler)(JSPrinter *jp) is not inside extern "C". That means this decompiler has c++ linkage. That make the overloads warning happened. If the function point in jsopcode.cpp has c linkage, this kind of warning will not happen. Attached patch is another solution based on this theory.
I see --- because the definition in jsopcodes.cpp is not in extern "C", its argument gets a C++ linkage function type, and it is seen as an overloading of the function declared in jsopcodes.h. I like the typedef solution. The type should be named JSDecompilerPtr. r=me with that change.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.