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

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[David Gardiner]

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
de/xpcom
perl -I../../config ../../config/build-
list.pl ../../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 
nsComOb
solete.h nsCWeakReference.h nsDebug.h nsError.h nsID.h nsIID.h nsIPtr.h 
nsISuppo
rtsBase.h nsISupportsImpl.h nsISupportsUtils.h nsISupportsObsolete.h 
nsIWeakRefe
renceUtils.h nsTraceRefcnt.h nsWeakReference.h nsWeakPtr.h nscore.h 
nsIInterface
RequestorUtils.h pure.h ../../dist/include/xpcom
perl -I../../config ../../config/build-
list.pl ../../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 
nsISupport
sUtils.h nsISupportsObsolete.h nsIWeakReferenceUtils.h nsTraceRefcnt.h 
nsWeakRef
erence.h nsWeakPtr.h nscore.h nsIInterfaceRequestorUtils.h pure.h
d:/mozilla_src/tools/bin/nsinstall -m 644 nsrootidl.idl nsISupports.idl 
nsIMemor
y.idl nsIErrorService.idl nsIInterfaceRequestor.idl nsIWeakReference.idl 
nsICons
oleService.idl nsIConsoleMessage.idl nsIConsoleListener.idl nsIException.idl 
nsI
ExceptionService.idl nsIProgrammingLanguage.idl ../../dist/idl
nsISupports.idl
../../dist/bin/xpidl.exe -m header -w -I ../../dist/idl -I. -o 
_xpidlgen/nsISupp
orts nsISupports.idl

Which causes the error:

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

Call stack:
 	ntdll.dll!77f51c96() 	
 	ntdll.dll!77f7e265() 	
 	libIDL-0.6.dll!10014e26() 	
 	libIDL-0.6.dll!100167ea() 	
 	libIDL-0.6.dll!10014a93() 	
 	libIDL-0.6.dll!100122ba() 	
 	libIDL-0.6.dll!10012275() 	
 	libIDL-0.6.dll!10014a60() 	
>	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
	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!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
	C
 	xpidl.exe!mainCRTStartup()  Line 400 + 0xe	C
 	kernel32.dll!77e7eb69() 	


Like 87 is the IDL_tree_to_IDL function call:

void
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 |
                    IDLF_OUTPUT_PROPERTIES);
    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

[David Bradley]

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

Comment 2

[David Bradley]

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

[David Gardiner]

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

-dave

Comment 4

[David Bradley]

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

[David Bradley]

Marking invalid. If the reporter still encounters problems feel free to reopen this.

Comment 6

[Phil Schwartau]

Marking Verified for now -

Comment 7

[David Gardiner]

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.

-dave

Comment 8

[David Bradley]

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 http://lxr.mozilla.org/seamonkey/source/build/autoconf/libIDL.m4 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

[David Gardiner]

Attachment: 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

[David Gardiner]

Attachment: Debug symbols for glib 1.3.13 and IDL 0.7 compiled with MSVC 7.0 (non-optimised)

Comment 11

[David Gardiner]

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

Precompiled versions of these can be found at 
http://www.gimp.org/~tml/gimp/win32/new-downloads.html 

* http://www.gimp.org/~tml/gimp/win32/libiconv-1.7.zip
* http://www.gimp.org/~tml/gimp/win32/libintl-0.10.40-20020101.zip


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.

-dave

Comment 12

[Jesse Ruderman]

Dup of bug 88437?

Comment 13

[David Bradley]

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.

Comment 14

[David Gardiner]

Yes, everything builds fine..

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

-dave

Comment 15

[David Bradley]

Adding seawood for some build input on this issue.

Comment 16

[hacker formerly known as [e-mail]]

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.

Comment 17

[hacker formerly known as [e-mail]]

*** Bug 88437 has been marked as a duplicate of this bug. ***

Comment 18

[hacker formerly known as [e-mail]]

Attachment: Build changes for pthreads-2001-07-03

Comment 19

[hacker formerly known as [e-mail]]

Attachment: Build changes for glib 1.2.10

Comment 20

[hacker formerly known as [e-mail]]

Attachment: Changes for libIDL-0.6.8

Comment 21

[hacker formerly known as [e-mail]]

VC7 built zips of glib 1.2.10 & libIDL 0.6.8 have been uploaded to the ftpsite.

ftp://ftp.mozilla.org/pub/mozilla/libraries/win32/vc7-glib-1.2.10-bin.zip
ftp://ftp.mozilla.org/pub/mozilla/libraries/win32/vc7-libIDL-0.6.8-bin.zip

Comment 22

[Phil Schwartau]

Marking Verified

Comment 23

[David Fraser]

Note: for building OpenOffice.org, 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

[David Bradley]

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

Comment 25

[David Fraser]

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...