From: Bo Y. <tec...@gm...> - 2007-11-21 12:31:44
|
Hi, I am trying to build Mozilla trunk source on MinGW and I get stumbled by the header files error. The problems are the MinGW win32api's header files is not consistent with the Microsoft Visual Studio 2005. And the source of Mozilla is written toward to the newst platform SDK in windows, which is MS 2005. Is there any way to get around of this? And what are the difference between the windows specific header files in MinGW and VC 6.0. Can I just copy the VC 8.0 header files to use here? Please help if you can, thank you in advance! Regards! Bo |
From: Aaron G. <an...@be...> - 2007-11-21 16:20:28
|
> Hi, > I am trying to build Mozilla trunk source on MinGW and I get stumbled > by the header files error. The problems are the MinGW win32api's header > files is not consistent with the Microsoft Visual Studio 2005. And the > source of Mozilla is written toward to the newst platform SDK in > windows, which is MS 2005. Is there any way to get around of this? > And what are the difference between the windows specific header files > in MinGW and VC 6.0. Can I just copy the VC 8.0 header files to use > here? Please help if you can, thank you in advance! Mozilla is built using Visual C++, it is really not a trivial port to MinGW f it can be done at all. VC 8.0 header files really cannot be used with GCC, and is probably prohibited by the licence. |
From: Bo Y. <tec...@gm...> - 2007-11-22 10:49:10
|
Aaron Gray : >> Hi, >> I am trying to build Mozilla trunk source on MinGW and I get stumbled >> by the header files error. The problems are the MinGW win32api's header >> files is not consistent with the Microsoft Visual Studio 2005. And the >> source of Mozilla is written toward to the newst platform SDK in >> windows, which is MS 2005. Is there any way to get around of this? >> And what are the difference between the windows specific header files >> in MinGW and VC 6.0. Can I just copy the VC 8.0 header files to use >> here? Please help if you can, thank you in advance! >> > > Mozilla is built using Visual C++, it is really not a trivial port to MinGW > f it can be done at all. > Are you a developer of Mozilla source code? I think Mozilla Firefox 2.* can be built with MinGW in windows. But now, the trunk source will only be built with VC 8. And the now MinGW win32 API is equal to VC 6. So, I can not build Mozilla with MinGW now. > VC 8.0 header files really cannot be used with GCC, and is probably > prohibited by the licence. > That is to say that the win32 API will be always in VC 6. right? Thank you for your reply! Regards! Bo |
From: Jonathan W. <jf...@tp...> - 2007-11-22 11:16:06
|
> Are you a developer of Mozilla source code? I think Mozilla Firefox 2.* > can be built with MinGW in windows. But now, the trunk source will only > be built with VC 8. And the now MinGW win32 API is equal to VC 6. So, I > can not build Mozilla with MinGW now. There is https://bugzilla.mozilla.org/show_bug.cgi?id=203303 which should contain pointers to all bugs preventing compilation with MingW. If the problems building trunk with MingW have been filed as bugs in bugzilla, then the relavent bugs should be marked as blocking 203303. If the problems building trunk with MingW are NOT filed as bugs in bugzilla, someone should do it. If someone can tell me how to get a build system working so that it will attempt to build trunk with MingW, I will take a look at why it wont build and see if I can come up with some fixes to submit to Mozilla team for it (since I have lots of free time right now) I was one of the people who was around when the initial work to make the source compile with MingW was carried out and I did actually write some code IIRC (I forget what though) As for the issue of VS6 versus VS2005 (i.e. VS8), the basic question is whether Mozilla requires windows API calls (and constants, definitions etc) that are present in the Visual C++ 2005 windows API headers but are not present in the MingW headers. If the answer is yes, it should simply be a matter of someone finding a source for the definitions that is acceptable for inclusion in MingW. |
From: Bo Y. <tec...@gm...> - 2007-11-22 13:39:49
|
Jonathan Wilson : >> Are you a developer of Mozilla source code? I think Mozilla Firefox 2.* >> can be built with MinGW in windows. But now, the trunk source will only >> be built with VC 8. And the now MinGW win32 API is equal to VC 6. So, I >> can not build Mozilla with MinGW now. >> > There is https://bugzilla.mozilla.org/show_bug.cgi?id=203303 which should > contain pointers to all bugs preventing compilation with MingW. If the > problems building trunk with MingW have been filed as bugs in bugzilla, > then the relavent bugs should be marked as blocking 203303. If the problems > building trunk with MingW are NOT filed as bugs in bugzilla, someone should > do it. > Thank you very much for the useful information. > If someone can tell me how to get a build system working so that it will > attempt to build trunk with MingW, I will take a look at why it wont build > and see if I can come up with some fixes to submit to Mozilla team for it > (since I have lots of free time right now) > Yeah, I just want to do that as well. :-) > I was one of the people who was around when the initial work to make the > source compile with MingW was carried out and I did actually write some > code IIRC (I forget what though) > > As for the issue of VS6 versus VS2005 (i.e. VS8), the basic question is > whether Mozilla requires windows API calls (and constants, definitions etc) > that are present in the Visual C++ 2005 windows API headers but are not > present in the MingW headers. If the answer is yes, it should simply be a > matter of someone finding a source for the definitions that is acceptable > for inclusion in MingW. > Yes, but how about the libraries? MinGW uses many import libraries for Windows platform DLL. If we just replace the header files,should we also make some new import libraries for the new classes and functions in the new headers? Thanks! Regards! Bo |
From: Jonathan W. <jf...@tp...> - 2007-11-22 13:42:02
|
> Yes, but how about the libraries? MinGW uses many import libraries for > Windows platform DLL. If we just replace the header files,should we also > make some new import libraries for the new classes and functions in the > new headers? > Thanks! Basically if we can get it to compile to the point where it says "error I cant find xyz" (where xyz is something present in the windows SDK header files but not the MingW header files) then the question of exactly what we need to add to MingW to get that working can be answered for each item on a case by case basis. |
From: Bo Y. <tec...@gm...> - 2007-11-22 14:36:18
|
Jonathan Wilson : >> Yes, but how about the libraries? MinGW uses many import libraries for >> Windows platform DLL. If we just replace the header files,should we also >> make some new import libraries for the new classes and functions in the >> new headers? >> Thanks! >> > Basically if we can get it to compile to the point where it says "error I > cant find xyz" (where xyz is something present in the windows SDK header > files but not the MingW header files) then the question of exactly what we > need to add to MingW to get that working can be answered for each item on a > case by case basis. > Yes, we can replace the header files. But I think there will also be some errors in linkage stage. And that is because some new added API in windows sdk DLLs. How can we deal with this? Make new import library? Regards! Bo |
From: Jonathan W. <jf...@tp...> - 2007-11-22 22:40:35
|
Just to follow up on this, I have managed to get it to attempt a build. I have all the components required for the Mozilla build installed. I have a .bat file that looks like this: PATH=c:\mozilla-build\moztools\bin;c:\mozilla-build\python25;c:\mozilla-build\info-zip;c:\msys\1.0\bin;c:\mingw\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\system32\WBEM set HOME=c:\home set GCC=yes set GXX=yes set CC=gcc set CXX=g++ set CPP=cpp set LD=ld set AS=as set MOZ_TOOLS=c:\mozilla-build\moztools my .mozconfig looks like this # # See http://www.mozilla.org/build/ for build instructions. # # Options for client.mk. mk_add_options MOZ_CO_PROJECT=suite mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ mk_add_options MOZ_MAKE_FLAGS=-j4 # Options for 'configure' (same as command-line options). ac_add_options --with-windows-version=501 ac_add_options --enable-application=suite ac_add_options --disable-accessibility ac_add_options --disable-installer Then I run the batch file and then build SeaMonkey with make -f client.mk build I end up hitting the following error: /c/mingw/bin/windres -O coff --use-temp-file -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ --include-dir c:/mozilla/obj-i686-pc-mingw32/dist/include/nspr --include-dir /c/mozilla/nsprpub/pr/include --include-dir /c/mozilla/nsprpub/pr/include/private -o nspr.res /c/mozilla/nsprpub/pr/src/nspr.rc c:/mozilla/nsprpub/pr/src/nspr.rc:38:20: error: prinit.h: No such file or directory c:\mingw\bin\windres.exe: c:\mingw\bin\gcc exited with status 1 Any ideas? Windres bug? Mozilla build system bug? Something I did wrong on my end? |
From: Bo Y. <tec...@gm...> - 2007-11-23 00:50:58
|
Jonathan Wilson : > Just to follow up on this, I have managed to get it to attempt a build. > I have all the components required for the Mozilla build installed. > I have a .bat file that looks like this: > PATH=c:\mozilla-build\moztools\bin;c:\mozilla-build\python25;c:\mozilla-build\info-zip;c:\msys\1.0\bin;c:\mingw\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\COMMAND;C:\WINDOWS\system32\WBEM > set HOME=c:\home > set GCC=yes > set GXX=yes > set CC=gcc > set CXX=g++ > set CPP=cpp > set LD=ld > set AS=as > set MOZ_TOOLS=c:\mozilla-build\moztools > > my .mozconfig looks like this > # > # See http://www.mozilla.org/build/ for build instructions. > # > > # Options for client.mk. > mk_add_options MOZ_CO_PROJECT=suite > mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ > mk_add_options MOZ_MAKE_FLAGS=-j4 > > # Options for 'configure' (same as command-line options). > ac_add_options --with-windows-version=501 > ac_add_options --enable-application=suite > ac_add_options --disable-accessibility > ac_add_options --disable-installer > > Then I run the batch file and then build SeaMonkey with make -f client.mk build > I end up hitting the following error: > /c/mingw/bin/windres -O coff --use-temp-file -DMOZILLA_CLIENT=1 -DNDEBUG=1 > -DXP_PC=1 -DWIN32=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 > -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ --include-dir > c:/mozilla/obj-i686-pc-mingw32/dist/include/nspr --include-dir > /c/mozilla/nsprpub/pr/include --include-dir > /c/mozilla/nsprpub/pr/include/private -o nspr.res > /c/mozilla/nsprpub/pr/src/nspr.rc > c:/mozilla/nsprpub/pr/src/nspr.rc:38:20: error: prinit.h: No such file or > directory > c:\mingw\bin\windres.exe: c:\mingw\bin\gcc exited with status 1 > > Any ideas? Windres bug? Mozilla build system bug? Something I did wrong on > my end? > Ah, I can figure out what is the problem behind the scene depending on what you give. Where did you get your source? Is that a complete some tree? I think the most valuable way to find the problem is to look up for prinit.h. To see whether it is really lost. And then you can go further for other possibilities. Thanks! Bo |
From: Jonathan W. <jf...@tp...> - 2007-11-23 11:59:10
|
> Ah, I can figure out what is the problem behind the scene depending on > what you give. Where did you get your source? Is that a complete some > tree? I think the most valuable way to find the problem is to look up > for prinit.h. To see whether it is really lost. And then you can go > further for other possibilities. > Thanks! > Bo Source is the complete source tree checked straight from mozilla.org CVS. prinit.h is right where it should be (in the include folder referenced in the failing command line) |
From: Jonathan W. <jf...@tp...> - 2007-11-24 08:33:30
|
I did some further investigation and copied the windres command manually and ran it. Same error. Adding -v to the windres command line caused windres to print out a GCC command line before printing the same error. However, if I copy and paste the GCC command line, it works and spits out precompiled source. So, something windres does before it runs GCC seems to be the culprit. For reference, the windres command line I am trying is this /c/mingw/bin/windres -v -O coff --use-temp-file -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ --include-dir c:/mozilla/obj-i686-pc-mingw32/dist/include/nspr --include-dir /c/mozilla/nsprpub/pr/include --include-dir /c/mozilla/nsprpub/pr/include/private -o nspr.res /c/mozilla/nsprpub/pr/src/nspr.rc and the GCC command line windres spits out is this c:\mingw\bin\gcc -E -xc -DRC_INVOKED -DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_PC=1 -DWIN32=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DHAVE_STRERROR=1 -DFORCE_PR_LOG -D_NSPR_BUILD_ -I"c:/mozilla/obj-i686-pc-mingw32/dist/include/nspr" -I"c:/mozilla/nsprpub/pr/include" -I"c:/mozilla/nsprpub/pr/include/private" "c:/mozilla/nsprpub/pr/src/nspr.rc" Any ideas? My binutils is 2.17.50 20070129, is there something else I could run that would be more likely to work? Are there any patches from Binutils trunk that would help? Do I need to pull out GDB and fix GCC/binutils myself? (I do have copyright assignment for both GCC and binutils) |
From: Tim S. <sta...@ve...> - 2007-11-24 09:19:12
|
Try it without --use-temp-file and see if it works, I think I read about a bug work around and use-temp-file. I can not remmeber if it was adding it or removing it that fixed the bug. Tim S |
From: Jonathan W. <jf...@tp...> - 2007-11-24 09:37:04
|
Tim Stahlhut wrote: > Try it without --use-temp-file and see if it works, I think I read about > a bug work around and use-temp-file. I can not remmeber if it was adding > it or removing it that fixed the bug. Removing --use-temp-file seems to make it work. However, there is a comment that --use-temp-file was added because of Mozilla bug 213281 so blanket removal may not be the answer. |
From: Jonathan W. <jf...@tp...> - 2007-11-24 12:54:14
|
I found the source code for glib and libidl but it wont compile with MingW. So we need to get it to compile with mingw somehow... |
From: John B. <joh...@ho...> - 2007-11-24 17:23:09
|
On Sat, 24 Nov 2007 21:54:06 +0900, Jonathan Wilson wrote: > > I found the source code for glib and libidl but it wont compile with Ming= W. > So we need to get it to compile with mingw somehow... > When you say "it won't compile", I assume that you mean neither GLib2 nor libidl compiles. I don't know about libidl, but I have compiled GLib 2.12.13 with MinGW. I don't remember if the entire package compiles "out of the box", but pkg-config reports the following: $ pkg-config --list-all | grep GLib gmodule-no-export-2.0 GModule - Dynamic module loader for GLib glib-2.0 GLib - C Utility Library gmodule-export-2.0 GModule - Dynamic module loader for GLib gobject-2.0 GObject - GLib Type, Object, Parameter and Signal Lib= rary gmodule-2.0 GModule - Dynamic module loader for GLib gthread-2.0 GThread - Thread support for GLib $ pkg-config --modversion glib-2.0 2.12.13 _________________________________________________________________ You keep typing, we keep giving. Download Messenger and join the i=92m Init= iative now. http://im.live.com/messenger/im/home/?source=3DTAGLM= |
From: Bo Y. <tec...@gm...> - 2007-11-25 03:43:18
|
Jonathan Wilson : > I found the source code for glib and libidl but it wont compile with MingW. > So we need to get it to compile with mingw somehow... > You don't need build it from source at all. The URL I point to works well for MinGW. Regards! Bo |
From: Jonathan W. <jf...@tp...> - 2007-11-24 09:45:29
|
Now it hits this error: gcc -mno-cygwin -o xpidl.exe -Wall -W -Wno-unused -Wpointer-arith -Wcast-align -Wno-long-long -pedantic -mms-bitfields -pipe -DNDEBUG -DTRIMMED -O -I/c/mozilla-build/moztools/include -I/c/mozilla-build/moztools/include xpidl.o xpidl_idl.o xpidl_util.o xpidl_header.o xpidl_typelib.o xpidl_doc.o xpidl_java.o ./module.res -L../../../dist/bin -L../../../dist/lib ../../../dist/lib/libxpt.a /c/mozilla-build/moztools/lib/libidl-0.6_s.lib /c/mozilla-build/moztools/lib/glib-1.2_s.lib -lm -lgdi32 -lwinmm -lwsock32 Info: resolving __iob by linking to __imp___iob (auto-import) Info: resolving __pctype by linking to __imp___pctype (auto-import) Info: resolving ___mb_cur_max by linking to __imp____mb_cur_max (auto-import) Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3d20): undefined reference to `_allmul' c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3db1): undefined reference to `_alldiv' c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3ee4): undefined reference to `_allrem' c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3f3a): undefined reference to `_allshr' c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3f90): undefined reference to `_allshl' fu000001.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' fu000004.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' fu000006.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' fu000008.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' fu000010.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' fu000012.o:(.idata$2+0xc): more undefined references to `libmsvcrt_a_iname' follow nmth000000.o:(.idata$4+0x0): undefined reference to `_nm___iob' nmth000141.o:(.idata$4+0x0): undefined reference to `_nm___pctype' nmth000160.o:(.idata$4+0x0): undefined reference to `_nm____mb_cur_max' Any ideas? (my guess is that libidl-0.6_s.lib being compiled with visual studio and not GCC is part of the problem but I haven't a clue where to get the source for that lib or how to build with MingW GCC) |
From: Bo Y. <tec...@gm...> - 2007-11-25 03:38:16
|
Jonathan Wilson : > Now it hits this error: > gcc -mno-cygwin -o xpidl.exe -Wall -W -Wno-unused -Wpointer-arith > -Wcast-align -Wno-long-long -pedantic -mms-bitfields -pipe -DNDEBUG > -DTRIMMED -O -I/c/mozilla-build/moztools/include > -I/c/mozilla-build/moztools/include xpidl.o xpidl_idl.o xpidl_util.o > xpidl_header.o xpidl_typelib.o xpidl_doc.o xpidl_java.o ./module.res > -L../../../dist/bin -L../../../dist/lib ../../../dist/lib/libxpt.a > /c/mozilla-build/moztools/lib/libidl-0.6_s.lib > /c/mozilla-build/moztools/lib/glib-1.2_s.lib -lm -lgdi32 -lwinmm -lwsock32 > Info: resolving __iob by linking to __imp___iob (auto-import) > Info: resolving __pctype by linking to __imp___pctype (auto-import) > Info: resolving ___mb_cur_max by linking to __imp____mb_cur_max (auto-import) > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" > /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" > /DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized > c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3d20): > undefined reference to `_allmul' > c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3db1): > undefined reference to `_alldiv' > c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3ee4): > undefined reference to `_allrem' > c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3f3a): > undefined reference to `_allshr' > c:/mozilla-build/moztools/lib/libidl-0.6_s.lib(parser.obj):parser.c:(.text+0x3f90): > undefined reference to `_allshl' > fu000001.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' > fu000004.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' > fu000006.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' > fu000008.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' > fu000010.o:(.idata$2+0xc): undefined reference to `libmsvcrt_a_iname' > fu000012.o:(.idata$2+0xc): more undefined references to `libmsvcrt_a_iname' > follow > nmth000000.o:(.idata$4+0x0): undefined reference to `_nm___iob' > nmth000141.o:(.idata$4+0x0): undefined reference to `_nm___pctype' > nmth000160.o:(.idata$4+0x0): undefined reference to `_nm____mb_cur_max' > > Any ideas? (my guess is that libidl-0.6_s.lib being compiled with visual > studio and not GCC is part of the problem but I haven't a clue where to get > the source for that lib or how to build with MingW GCC) > Yes, your guess is right. I have came across this error, too. Please use this one http://ftp.mozilla.org/pub/mozilla.org/mozilla/source/wintools.zip. Regards! Bo |
From: Keith M. <kei...@us...> - 2007-11-24 22:05:27
|
On Sat, 2007-11-24 at 17:33 +0900, Jonathan Wilson wrote: > My binutils is 2.17.50 20070129, Oh, oh. There was a windres patch in that service update, to let it handle spaces in path names, (yuk). Given other recent complaints relating to windres, it looks like this may have broken it. > is there something else I could run that would be more likely to work? It may be worth reverting to binutils-2.17.50 `current' release, or ... > Are there any patches from Binutils trunk that would help? Do I need > to pull out GDB and fix GCC/binutils myself? Chris has been looking at binutils-2.18.50, which he has successfully built with, and for MinGW, and which appears not to exhibit this bug. I've asked him to post it as a tech preview release, so you may like to try that, when he manages to get it to the SF file release system; (I'm having difficulty connecting at present). Regards, Keith. |
From: Brian D. <br...@de...> - 2007-11-23 02:49:52
|
Bo Yang wrote: > I am sorry if I did not convey my question clearly. I mean, win32 API is > equal to the platform sdk shipped with VC 6. That is to say the header > files and libraries are equal to the ones of VC 6 SDK version. And now > MS VC 8 provide more new Macros, functions and many other new feature in > the new SDK shipped with VC 8. Can win32 API now support them, too? Thanks! The platform SDK (now called just Windows SDK) is completely separate from the Visual Studio product. They are updated at different times, and you can mix and match versions. If there are functions, macros, or structures that are currently missing from w32api (and there certainly are) they can easily be added as long as there is public documentation to derive them from and someone submits a patch. > So, a further question. What is the WINVER is I want to use the new > feature of the SDK shipped with VC 8? Stop talking about VC versions. That has nothing to do with anything. Whenever you look at the documentation for a Win32 function on MSDN it will show the versions of Windows that support that interface. You #define _WIN32_WINNT to the number that corresponds to the desired version of Windows that you want your program to require before including the Windows headers. This is documented at <http://msdn2.microsoft.com/en-us/library/aa383745.aspx>. > And I have some more questions, could you please help on some if you can. > 1. If there new functions in the new SDK dll, do we need to modify our > import libraries? For example, if MS add a new function into the > kernel32.dll, and now we want to use the function. So, we should add the > new function into our header file firstly and then add it into the > import library "libkernel32.a", am I right? If the answer is yes, how > can I add it to the libkernel32.a? How do you produce so many lib....a > from the DLL? Yes, generally adding support for a new function requires adding it to both a header and the .def file, which is what the import libraries are generated from. Look at the source code of w32api if you want details. > 2. Can we link to the windows DLL directly without the import libraries? No. The Win32 API libraries use a rather antiquated combination of calling convention and decoration (stdcall without @nn decoration) that requires linking with import libraries in order to provide the aliases. gcc always adds the decorations when using stdcall calling convention, so if you tried to link without the import library you'd get undefined references. This is a particular artifact of the Win32 API however, not of DLLs in general. > 3. I know windows linker use import libraries to link to DLL, and could > you please tell me that is that the only way to link to a DLL? Can I > link to a DLL directly with windows VC linker? And How about the GNU ld > linker? Stop asking about VC. This is not a support forum for VC. You need to read the Win32 section of the ld manual: <http://sourceware.org/binutils/docs-2.18/ld/WIN32.html>. It explains all of this. It is possible to link directly against a DLL with GNU ld, you just specify its name on the command line like any other object file. However there are certain things that import libraries provide that you cannot otherwise accomplish, so you have to be aware that this will not always work. I feel like I've already typed out this explanation before so I'll just point to a copy of that message: <http://lists.gnu.org/archive/html/libtool/2007-08/msg00026.html>. Brian |
From: Bo Y. <tec...@gm...> - 2007-11-23 03:16:02
|
Brian Dessent : Thanks for your help, I will follow your links and learn more there. Thanks again! Regards! Bo |
From: Keith M. <kei...@us...> - 2007-11-22 23:08:50
|
On Thu, 2007-11-22 at 18:48 +0800, Bo Yang wrote: > I think Mozilla Firefox 2.* can be built with MinGW in windows. But > now, the trunk source will only be built with VC 8. And the now MinGW > win32 API is equal to VC 6. Huh? What do VC6 or VC8 have to do with the price of eggs? MinGW's w32api supports features of the OPERATING SYSTEM, not of any version of any compiler purchased from Microsnot. > That is to say that the win32 API will be always in VC 6. right? w32api will support whatever features of Woe32 operating systems, of *any* version, that we are able to support on the basis of freely and publicly documented interface details; nothing whatever to do with any particular version of any Microsnot compiler. Some sections of the headers contain conditional defines; by default, only features supported on all Woe32 versions from w95 onward, (with an appropriate version of IE installed -- I forget just which exactly -- to provide MSVCRT[*]); you may *choose*, at compile time, to enable more recent features, provided you are willing to sacrifice the backward compatibility, simply by ensuring that WINVER is appropriately defined. Regards, Keith. [*] Yes, that is coincidentally the MSVCRT derived from VC6, but it is now a core OS component; we target it on that basis, *not* to achieve compatibility with VC6. We also provide import libs for more recent versions of MSVCRT, but we don't link with them by default, because not everybody with a Woe32 system will necessarily have them. You are free to configure *your* MinGW installation to substitute them, if you are willing to sacrifice portability of *your* applications to systems which lack the specific version you choose to deploy. |
From: Bo Y. <tec...@gm...> - 2007-11-23 00:46:41
|
Keith Marshall : > On Thu, 2007-11-22 at 18:48 +0800, Bo Yang wrote: > >> I think Mozilla Firefox 2.* can be built with MinGW in windows. But >> now, the trunk source will only be built with VC 8. And the now MinGW >> win32 API is equal to VC 6. >> > > Huh? What do VC6 or VC8 have to do with the price of eggs? MinGW's > w32api supports features of the OPERATING SYSTEM, not of any version of > any compiler purchased from Microsnot. > I am sorry if I did not convey my question clearly. I mean, win32 API is equal to the platform sdk shipped with VC 6. That is to say the header files and libraries are equal to the ones of VC 6 SDK version. And now MS VC 8 provide more new Macros, functions and many other new feature in the new SDK shipped with VC 8. Can win32 API now support them, too? Thanks! >> That is to say that the win32 API will be always in VC 6. right? >> > > w32api will support whatever features of Woe32 operating systems, of > *any* version, that we are able to support on the basis of freely and > publicly documented interface details; nothing whatever to do with any > particular version of any Microsnot compiler. Some sections of the > headers contain conditional defines; by default, only features supported > on all Woe32 versions from w95 onward, (with an appropriate version of > IE installed -- I forget just which exactly -- to provide MSVCRT[*]); > you may *choose*, at compile time, to enable more recent features, > provided you are willing to sacrifice the backward compatibility, simply > by ensuring that WINVER is appropriately defined. > So, a further question. What is the WINVER is I want to use the new feature of the SDK shipped with VC 8? > [*] Yes, that is coincidentally the MSVCRT derived from VC6, but it is > now a core OS component; we target it on that basis, *not* to achieve > compatibility with VC6. We also provide import libs for more recent > versions of MSVCRT, but we don't link with them by default, because not > everybody with a Woe32 system will necessarily have them. You are free > to configure *your* MinGW installation to substitute them, if you are > willing to sacrifice portability of *your* applications to systems which > lack the specific version you choose to deploy. > So, do you mind to tell me about how to configure my MinGW installation to substitue "them" ? And I have some more questions, could you please help on some if you can. 1. If there new functions in the new SDK dll, do we need to modify our import libraries? For example, if MS add a new function into the kernel32.dll, and now we want to use the function. So, we should add the new function into our header file firstly and then add it into the import library "libkernel32.a", am I right? If the answer is yes, how can I add it to the libkernel32.a? How do you produce so many lib....a from the DLL? 2. Can we link to the windows DLL directly without the import libraries? 3. I know windows linker use import libraries to link to DLL, and could you please tell me that is that the only way to link to a DLL? Can I link to a DLL directly with windows VC linker? And How about the GNU ld linker? Thanks very much! Regards! Bo |