Compile errors using LLVM 2.0 (Clang)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Open the a Firebreath project in Xcode 4.
2. Set the compiler to LLVM 2.0
3. Compile ScriptingCore and UnitTest_ScriptingCore. There may be link errors 
if you try BUILD_ALL; ignore these for now as I think it's a problem with Xcode 
4.

What is the expected output? What do you see instead?
Expected successful compilation. Saw three build errors:

variant.h:377& 379 "'object' is a private member of 'FB::variant'"
I'm not entirely sure how this compiles under GCC and MSVC. It looks pretty 
straightforward to me, which might mean I'm missing something subtle and that 
this is actually a bug in Clang.

TypeIDMap.h:86 "Calling a private constructor of 'std::type_info'"
The type_info copy constructor is indeed declared private in GCC's 
typeinfo.h:135 (and MSDN agrees: 
http://msdn.microsoft.com/en-us/library/70ky2y6k(VS.80).aspx). According to 
http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.11, "Objects that 
are thrown must have a publicly accessible copy-constructor." It appears that 
GCC and MSVC are providing a workaround by guaranteeing that the thrown typeid 
is not copied. A simple workaround is to throw an std::bad_typeinfo exception 
instead.

What version of FireBreath are you using? On what operating system and
browsers?

1.1.1 release
Mac OS X 10.6

Please provide any additional information below.

Original issue reported on code.google.com by richcata...@gmail.com on 30 Jul 2010 at 9:42

[GoogleCodeExporter]

variant.h:
Yep, i am surprised that this wasn't catched by GCC/MSVC.
variant_cast should probably just forward to a member function.

TypeIDMap.h:
Yep, C++03 says so in §18.5.1, §15.1.5 makes it rather clear that an 
accessible copy-ctor is required even if the actual copying can be eliminated. 
As 5.2.8 guarantees that the instance typeid returns lives until the end of the 
program, throwing a pointer (i.e. "throw &typeid(foo);" would work just fine. I 
don't really see what code would be affected by this - Richard, do you?

Original comment by georg.fritzsche on 31 Jul 2010 at 7:49

• Changed state: Accepted

[GoogleCodeExporter]

variant.h is fixed.
Looking at the sources again i'd say 'throw typeid(void);' could just as well 
become 'throw std::runtime_error("no such typeid");' - or is that line a typo 
and should have been 'return typeinfo(void);'?

Original comment by georg.fritzsche on 31 Jul 2010 at 8:13

[GoogleCodeExporter]

Yeah, that line should have been:

return typeid(void); 

richcatalano, could you truy changing line 86 of TypeIDMap.h to a return 
statement and let us know if it fixes the problem?  I don't have xcode 4 to 
test.

Original comment by taxilian on 31 Jul 2010 at 11:35

[GoogleCodeExporter]

That produces the following error:
"Binding of reference to type 'std::type_info' to a value of type 
'std::type_info const' drops qualifiers"

Original comment by richcata...@gmail.com on 9 Aug 2010 at 6:48

[GoogleCodeExporter]

That method should return a "const std::type_info&", commited a fix.

Original comment by georg.fritzsche on 9 Aug 2010 at 9:14

[GoogleCodeExporter]

Awesome.

The only other issue I'm having is that it doesn't like the redefinition of 
main in np_macmain.cpp(first argument should be int, second char **, etc.). I 
suspect this is an issue with the compiler, unless there is a specific flag 
needed to allow a redefinition of main. Omitting main upsets the linker (can't 
find "_main").  I can work around it with the following:

    #define main fake_main
    int fake_main(NPNetscapeFuncs *browserFuncs, NPPluginFuncs *pluginFuncs, NPP_ShutdownProcPtr *shutdown) asm("_main");

To me it seems most likely to be either an issue with Clang or a missing flag.

Original comment by richcata...@gmail.com on 9 Aug 2010 at 10:06

[GoogleCodeExporter]

This is most likely an error in the npapi header files somewhere or a missing 
#define.

int main is defined in one of the headers, and depending on the platform it is 
defined differently.

Original comment by taxilian on 9 Aug 2010 at 10:49

[GoogleCodeExporter]

Apparently this isn't coming from the NPAPI headers - it might be that Apple 
dropped support for CFM modules with Clang?

For the moment you could add "_NO_MAIN" to the preprocessor definitions for 
your plugin project, that should take care of it.

Original comment by georg.fritzsche on 10 Aug 2010 at 10:10

[GoogleCodeExporter]

That wouldn't surprise me.

Is the CFM module still needed?

Original comment by richcata...@gmail.com on 10 Aug 2010 at 10:59

[GoogleCodeExporter]

That main function is needed to support CFM browsers with the plugins. I have 
no idea what the statistics on CFM browsers being still alive are though. Maybe 
_NO_MAIN could become the default later if they don't have any critical mass 
anymore.

Original comment by georg.fritzsche on 10 Aug 2010 at 11:33

[GoogleCodeExporter]

According to this technote Mozilla moved to mach-o quite a long time ago.

http://www.mozilla.org/projects/plugins/plugin_scripting_ABI_technote.html

Original comment by richcata...@gmail.com on 11 Aug 2010 at 12:46

[GoogleCodeExporter]

If someone can get me a copy of XCode 4, I'll try to fix this.

Original comment by taxilian on 9 Sep 2010 at 2:08

[GoogleCodeExporter]

Original comment by taxilian on 16 Sep 2010 at 5:32

• Added labels: Milestone-Release1.3

[GoogleCodeExporter]

After having played with it a bit in preview release 3, I'm forced to conclude 
that we're not going to be able to do anything with this until Xcode4 and a 
cmake that supports it fully come out.

Original comment by taxilian on 21 Sep 2010 at 3:37

• Changed state: WontFix