> > > The only compiler/make system known to work is MSVC. It shouldn't be too
> > > much work to get the *code* to compile under gcc/egcs, but the make system
> > > would have to be revamped. Chris Seawood has worked on that on and off for a
> > I agree, that perhaps it won't be hard to make mozilla to compile with other
> > win32 compilers, but there is another problem. There are ppl out there that
> > develop program based on mozilla and they might have problems *if* they use
> > different compiler. Problem is that mozilla uses classes for creating
> > instances of object, instead of C API like CoCreateInstance. These classes
> > will have their names mangled differently which will produce errors at link
> > time. I think it would be a good idea to have C functiona for creating and
> > registering classes - this will make things almost compiler independant, since
> > most C++ compilers I've used actually generate code which is binary compatible
> > in terms of accessing vtbl etc.
> >
> Isn't the point of COM (and XPCOM) to avoid this nonsense?
> It should work just fine, since all objects in mozilla are XPCOM objects.
Perhaps I didn't express myself very well. Yes, you are absolutely right about
what you saying, but what I had in mind is that you need to create an instance
of an object somehow. The problem arise that you have to use expressions like
nsComponentManager::CreateInstance. If library module containing this method
is compiled with one compiler, and you try to use it from an application
written with different one, then you will get a link error. On the other hand,
if the previous statement is declared like
extern "C" NS_RESULT nsCreateInstance(arg,arg) then things become compiler
independent as long as compiler support vtbl compatible with one used to build
mozilla itself.
Anyway this is pure theory, since there are plenty of other thinfs like
nsString which will make things incompatible between compilers :(
--
--
Regards,
Waleri
