Need .Net/VC++ 7.0 version of libidl and glib

VERIFIED FIXED in mozilla1.2final



16 years ago
10 years ago


(Reporter: David Gardiner, Assigned: David Bradley)


Windows XP

Firefox Tracking Flags

(Not tracked)



(5 attachments)



16 years ago
Building mozilla on Windows XP Pro, with Visual Studio.NET (VC++7.0)

The build progresses to this bit:

make[4]: Entering directory `/cygdrive/d/mozilla_src/mozilla/xpcom/glue'
d:/mozilla_src/tools/bin/nsinstall -m 644 nsCOMPtr.h 
nsMemory.h ../../dist/inclu
perl -I../../config ../../config/build- ../../dist/include/xpcom/.headerl
ist nsCOMPtr.h nsMemory.h
make[4]: Leaving directory `/cygdrive/d/mozilla_src/mozilla/xpcom/glue'
make[4]: Entering directory `/cygdrive/d/mozilla_src/mozilla/xpcom/base'
d:/mozilla_src/tools/bin/nsinstall -m 644 nsAgg.h nsIAllocator.h nsCom.h 
solete.h nsCWeakReference.h nsDebug.h nsError.h nsID.h nsIID.h nsIPtr.h 
rtsBase.h nsISupportsImpl.h nsISupportsUtils.h nsISupportsObsolete.h 
renceUtils.h nsTraceRefcnt.h nsWeakReference.h nsWeakPtr.h nscore.h 
RequestorUtils.h pure.h ../../dist/include/xpcom
perl -I../../config ../../config/build- ../../dist/include/xpcom/.headerl
ist nsAgg.h nsIAllocator.h nsCom.h nsComObsolete.h nsCWeakReference.h nsDebug.h
nsError.h nsID.h nsIID.h nsIPtr.h nsISupportsBase.h nsISupportsImpl.h 
sUtils.h nsISupportsObsolete.h nsIWeakReferenceUtils.h nsTraceRefcnt.h 
erence.h nsWeakPtr.h nscore.h nsIInterfaceRequestorUtils.h pure.h
d:/mozilla_src/tools/bin/nsinstall -m 644 nsrootidl.idl nsISupports.idl 
y.idl nsIErrorService.idl nsIInterfaceRequestor.idl nsIWeakReference.idl 
oleService.idl nsIConsoleMessage.idl nsIConsoleListener.idl nsIException.idl 
ExceptionService.idl nsIProgrammingLanguage.idl ../../dist/idl
../../dist/bin/xpidl.exe -m header -w -I ../../dist/idl -I. -o 
orts nsISupports.idl

Which causes the error:

Unhandled exception at 0x77f51c96 in xpidl.exe: 0xC0000005: Access violation 
writing location 0x00000010.

Call stack:
>	xpidl.exe!xpidl_write_comment(TreeState * state=0x0012fee4, int 
indent=2)  Line 87 + 0x1b	C
 	xpidl.exe!op_dcl(TreeState * state=0x0012fee4)  Line 1100 + 0xb	C
 	xpidl.exe!xpidl_process_node(TreeState * state=0x0012fee4)  Line 64 + 
0x7	C
 	xpidl.exe!list(TreeState * state=0x0012fee4)  Line 617 + 0x9	C
 	xpidl.exe!xpidl_process_node(TreeState * state=0x0012fee4)  Line 64 + 
0x7	C
 	xpidl.exe!interface(TreeState * state=0x0012fee4)  Line 263 + 0x12
 	xpidl.exe!xpidl_process_node(TreeState * state=0x0012fee4)  Line 64 + 
0x7	C
 	xpidl.exe!list(TreeState * state=0x0012fee4)  Line 617 + 0x9	C
 	xpidl.exe!xpidl_process_node(TreeState * state=0x0012fee4)  Line 64 + 
0x7	C
 	xpidl.exe!xpidl_process_idl(char * filename=0x003a2cca, 
IncludePathEntry * include_path=0x003a2ce8, char * file_basename=0x003a2cb4, 
ModeData * mode=0x004154a8)  Line 772 + 0x9	C
 	xpidl.exe!main(int argc=10, char * * argv=0x003a2c38)  Line 214 + 0x1b
 	xpidl.exe!mainCRTStartup()  Line 400 + 0xe	C

Like 87 is the IDL_tree_to_IDL function call:

xpidl_write_comment(TreeState *state, int indent)
    fprintf(state->file, "%*s/* ", indent, "");
    IDL_tree_to_IDL(state->tree, state->ns, state->file,
                    IDLF_OUTPUT_NO_NEWLINES |
                    IDLF_OUTPUT_NO_QUALIFY_IDENTS |
    fputs(" */\n", state->file);

I've had a go at trying to build a libIDL with symbols, but it isn't the 
easiest thing in the world to do on a Windows box.

Comment 1

16 years ago
*** Bug 123754 has been marked as a duplicate of this bug. ***

Comment 2

16 years ago
I suspect the prebuilt libidl/glib that is available isn't compatible with the
new VC++ 7.0. Short of building a new libidl you might hunt around for any
compiler/linker options that might provide backward compatibility with old lib's.

If you rebuild libidl and glib with 7.0, post the results please.

Comment 3

16 years ago
Out of interest, i thought i'd try and compile glib1.3.13 and libIDL0.7 

i managed to get the DLL's, but i'm not having any luck convincing Mozilla to 
use these DLL's.

I think it is something to do with the autoconf stuff - i've tried to hardcode 
in the new version, but for some reason it keeps coming back and says it is 
going to use the old ones.

i'll keep playing


Comment 4

16 years ago
I believe they have to be in %MOZ_TOOLS%\lib Once you've built them, rename the
old ones and then copy them there.

Comment 5

16 years ago
Marking invalid. If the reporter still encounters problems feel free to reopen this.
Last Resolved: 16 years ago
Resolution: --- → INVALID

Comment 6

16 years ago
Marking Verified for now -


16 years ago
Blocks: 127985

Comment 7

16 years ago
Ok.. beats me how you are supposed to tell the Mozilla build system to use a 
different version of libIDL and glib :-(

So, as a last resort, i renamed libglib-1.3-13.dll to libglib-1.2.dll and 
libIDL-0.7.dll to libIDL-0.6.dll.

Yes, it is a nasty hack, but it fooled the thing into working.

I'll attach a zip of all the dll's I built that need to go into the 
MOZ_TOOLS\bin directory.

No longer blocks: 127985
Resolution: INVALID → ---

Comment 8

16 years ago
It looks like it searches and finds a libidl library. The minimum version is
defined as 0.6.3. glib's minimum version 1.2.0. So as long as you compile the
libraries and put them in the %MOZ_TOOLS%\bin|lib directories. You'll probably
need to remove the old ones in order for it pick them up. I'm not a build guru,
and couldn't tell if autoconf picked up the first one it found or the newest one.

Looks like is
the key. Line 46 seems to indicate it's locked into using 0.6.3-0.6.7 and the
hack would have to be removed in order to use other versions.

Comment 9

16 years ago
Created attachment 71742 [details]
glib 1.3.13 and IDL 0.7 compiled with MSVC 7.0 (non-optimised)

You also need iconv.dll and libintl-1.dll which are separate.

Comment 10

16 years ago
Created attachment 71743 [details]
Debug symbols for glib 1.3.13 and IDL 0.7 compiled with MSVC 7.0 (non-optimised)

Comment 11

16 years ago
You also need to copy iconv.dll and libintl-1.dll into MOZ_TOOLS\bin.

Precompiled versions of these can be found at 


If i get a chance, i'll try and compile optimised versions of the other DLLs I 
attached, but at least those ones get you started.



16 years ago
Blocks: 127985

Comment 12

16 years ago
Dup of bug 88437?

Comment 13

16 years ago
This is not really a dupe of bug 88437. In bug 88437, the problem was the
existing of .Net on the system. They weren't actually trying to build with the
.Net compiler/linker.

We have a general problem, whether it be .Net or GCC 3.x or any other compiler,
in that the libidl and glib libraries need to be built on that platform.

I'm downgrading this for now, as building with VC++ 7.0 aka .Net isn't a
priority currently. Feel free to disagree and reset severity/milestone.

Changing summary from xpidl.exe crashes with access violation (0xC0000005) to
reflect the real issue

Want to thank David Gardiner for doing the work to create the binaries, I'm sure
others will find them useful.

David G., were you able to build after getting those built? I have a sneaking
suspicion that XPTCall stuff may need to be adjusted, hard to say.
Severity: critical → normal
Summary: xpidl.exe crashes with access violation (0xC0000005) → Need .Net/VC++ 7.0 version of libidl and glib
Target Milestone: --- → Future

Comment 14

16 years ago
Yes, everything builds fine..

Once i got those libraries working, i've been pulling and building from the 
trunk every few days with success.


Comment 15

16 years ago
Adding seawood for some build input on this issue.
If we are going to actually start support building with VC7 then as the "vendor"
of the binary libIDL & dll package, we'll need to make a VC7-compatible package
available.  Wrt the configure tests, yes, we are hardcoded to use the glib 1.2.x
& libIDL 0.6.x apis.  I'm surprised that jumping to glib 1.3 & libIDL 0.7 worked
at all.  I would recommend sticking with the current sources that we are using
rather than bumping the rev as we bump the compiler.
*** Bug 88437 has been marked as a duplicate of this bug. ***
Created attachment 103263 [details] [diff] [review]
Build changes for pthreads-2001-07-03
VC7 built zips of glib 1.2.10 & libIDL 0.6.8 have been uploaded to the ftpsite.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
Target Milestone: Future → mozilla1.2final

Comment 22

16 years ago
Marking Verified

Comment 23

12 years ago
Note: for building, I have added some code to autobuild these
libraries from source. It seems like the glib library doesn't actually need
pthreads for what its used for here, so I hacked it out.
I also wonder whether its really neccessary to have these binaries, it would be
nicer to compile from source ;-)

Comment 24

12 years ago
I believe there were licensing issues and that's why we build against the
binaries and do not use the source.

Comment 25

12 years ago
libIDL is LGPL, glib is LGPL.
pthreads-win32 is LGPL, but is not actually needed for building mozilla
from the actual build tools zip, make is GPL.
uname, shmsdos and nsinstall don't seem to have any license or copyirght
information at all - these are fairly small simple tools and could be replaced
if neccessary:
$ wc -l uname/*.c shmsdos/*.c
  155 uname/uname.c
  697 shmsdos/nsinstall.c
 2573 shmsdos/shmsdos.c
I could open a separate issue if neccessary...


10 years ago
Component: xpidl → XPCOM
QA Contact: pschwartau → xpcom
You need to log in before you can comment on or make changes to this bug.