Closed Bug 328499 Opened 18 years ago Closed 18 years ago

Mingw build errors building cairo-windows (need to apply patches to MinGW; including mlang.h and usp10.h)

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: martijn.martijn, Assigned: engel)

References

Details

(Whiteboard: See Comment 48 for instructions how to easily update MinGW from CVS)

Attachments

(3 files)

Properly declare constructor of |gfxWindowsFonts|
1.06 KB, patch
vlad
: review+
Details | Diff | Splinter Review
fix mingw build issues
14.86 KB, patch
Details | Diff | Splinter Review
Updated MinGW w32api files, cygwin file locations given in Comment 60 (for msys see Comment 48)
31.93 KB, application/x-zip-compressed
Details 
See bug 324560, comment 6:

"
The patch seems to have caused the following on my Win32/cygwin/MinGW system :-

In file included from
e:/mozilla/source/mozilla/gfx/thebes/src/gfxPlatform.cpp:4
1:
../../../dist/include/thebes/gfxWindowsPlatform.h:47:19: mlang.h: No such file
o
r directory
In file included from
e:/mozilla/source/mozilla/gfx/thebes/src/gfxPlatform.cpp:4
1:
../../../dist/include/thebes/gfxWindowsPlatform.h:65: error: ISO C++ forbids
dec
laration of `IMultiLanguage' with no type
../../../dist/include/thebes/gfxWindowsPlatform.h:65: error: expected `;'
before
 '*' token
../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: `IMultiLanguage'
wa
s not declared in this scope
../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: template argument
1
 is invalid
../../../dist/include/thebes/gfxWindowsPlatform.h:75: error: ISO C++ forbids
dec
laration of `mMLang' with no type
make[6]: *** [gfxPlatform.o] Error 1
"

and bug 324560, comment 7:
"
huh. that is exciting.  not sure what to do about that.  I haven't really done
any mingw builds ever, but doing a quick google search makes it look like there
is might be some mingw mlang support somewhere.  Anyone know?
"
No longer blocks: 324560
When I add mlang.h to C:\mozilla\mozilla\dist\include\thebes, then I don't get this build error anymore, but instead I get this build error:

fxWindowsFonts.cpp
In file included from c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:44:
../../../dist/include/thebes/gfxWindowsFonts.h:45:19: Usp10.h: No such file or d
irectory
In file included from c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:44:
../../../dist/include/thebes/gfxWindowsFonts.h:60: error: extra qualification `
   gfxWindowsFont::' on member `gfxWindowsFont' ignored
../../../dist/include/thebes/gfxWindowsFonts.h:68: error: syntax error before `
   *' token
../../../dist/include/thebes/gfxWindowsFonts.h: In member function `virtual
   const gfxFont::Metrics& gfxWindowsFont::GetMetrics()':
../../../dist/include/thebes/gfxWindowsFonts.h:64: error: `mMetrics' undeclared

   (first use this function)
../../../dist/include/thebes/gfxWindowsFonts.h:64: error: (Each undeclared
   identifier is reported only once for each function it appears in.)
../../../dist/include/thebes/gfxWindowsFonts.h: In member function `
   cairo_font_face_t* gfxWindowsFont::CairoFontFace()':
../../../dist/include/thebes/gfxWindowsFonts.h:66: error: `mFontFace'
   undeclared (first use this function)
../../../dist/include/thebes/gfxWindowsFonts.h: In member function `
   cairo_scaled_font_t* gfxWindowsFont::CairoScaledFont()':
../../../dist/include/thebes/gfxWindowsFonts.h:67: error: `mScaledFont'
   undeclared (first use this function)
../../../dist/include/thebes/gfxWindowsFonts.h: At global scope:
../../../dist/include/thebes/gfxWindowsFonts.h:69: error: ISO C++ forbids
   defining types within return type
../../../dist/include/thebes/gfxWindowsFonts.h:69: error: syntax error before `
   (' token
../../../dist/include/thebes/gfxWindowsFonts.h:72: error: syntax error before `
   protected'
../../../dist/include/thebes/gfxWindowsFonts.h:77: error: syntax error before `
   private'
../../../dist/include/thebes/gfxWindowsFonts.h:83: error: `
   cairo_font_face_t*mFontFace' used prior to declaration
../../../dist/include/thebes/gfxWindowsFonts.h:84: error: `
   cairo_scaled_font_t*mScaledFont' used prior to declaration
../../../dist/include/thebes/gfxWindowsFonts.h:86: error: `gfxFont::Metrics
   mMetrics' used prior to declaration
../../../dist/include/thebes/gfxWindowsFonts.h:88: error: 'SCRIPT_CACHE' is
   used as a type, but is not defined as a type.
../../../dist/include/thebes/gfxWindowsFonts.h:91: error: syntax error before `
   }' token
In file included from ../../../dist/include/thebes/gfxWindowsPlatform.h:47,
                 from c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:46:
../../../dist/include/thebes/mlang.h:1: warning: ignoring #pragma warning
In file included from ../../../dist/include/thebes/gfxWindowsPlatform.h:47,
                 from c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:46:
../../../dist/include/thebes/mlang.h:188: warning: ignoring #pragma comment
In file included from c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:49:
../../../dist/include/thebes/mlang.h:1: warning: ignoring #pragma warning
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In constructor `
   gfxWindowsFont::gfxWindowsFont(const nsAString_internal&, const
   gfxFontGroup*, HDC__*)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:63: error: class `
   gfxWindowsFont' does not have any field named `mFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:63: error: class `
   gfxWindowsFont' does not have any field named `mScriptCache'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:63: error: class `
   gfxWindowsFont' does not have any field named `mIsMLangFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:69: error: `
   MakeCairoFontFace' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:77: error: `
   ComputeMetrics' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In constructor `
   gfxWindowsFont::gfxWindowsFont(HFONT__*, const gfxFontGroup*, int)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:84: error: class `
   gfxWindowsFont' does not have any field named `mScriptCache'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:84: error: class `
   gfxWindowsFont' does not have any field named `mIsMLangFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In destructor `virtual
   gfxWindowsFont::~gfxWindowsFont()':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:118: error: `mScriptCache
   ' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:118: error: `
   ScriptFreeCache' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: At global scope:
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:123: error: no `void
   gfxWindowsFont::UpdateFonts(cairo_t*)' member function declared in class `
   gfxWindowsFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:135: error: no `
   cairo_font_face_t* gfxWindowsFont::MakeCairoFontFace()' member function
   declared in class `gfxWindowsFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:149: error: no `
   cairo_scaled_font_t* gfxWindowsFont::MakeCairoScaledFont(cairo_t*)' member
   function declared in class `gfxWindowsFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:170: error: no `void
   gfxWindowsFont::ComputeMetrics(HDC__*)' member function declared in class `
   gfxWindowsFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In member function `void

   gfxWindowsFont::ComputeMetrics(HDC__*)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:182: warning: unused
   variable `gfxFloat descentPos'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: At global scope:
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:245: error: no `void
   gfxWindowsFont::FillLogFont()' member function declared in class `
   gfxWindowsFont'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In member function `void

   gfxWindowsFont::FillLogFont()':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:248: warning: assignment
   to `LONG' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:248: warning: argument to

   `long int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In member function `
   virtual void gfxWindowsTextRun::DrawString(gfxContext*, gfxPoint)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:331: warning: passing `
   gfxFloat' for argument 3 of `PRInt32
   gfxWindowsTextRun::MeasureOrDrawUniscribe(gfxContext*, int, int, int, const
   PRInt32*)'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:331: warning: passing `
   gfxFloat' for argument 4 of `PRInt32
   gfxWindowsTextRun::MeasureOrDrawUniscribe(gfxContext*, int, int, int, const
   PRInt32*)'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In member function `
   gfxWindowsFont* gfxWindowsTextRun::FindFallbackFont(HDC__*, const
   PRUnichar*, unsigned int, gfxWindowsFont*)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:356: error: `GetHFONT'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp: In member function `
   PRInt32 gfxWindowsTextRun::MeasureOrDrawUniscribe(gfxContext*, int, int,
   int, const PRInt32*)':
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:394: error: `::
   ScriptIsComplex' undeclared (first use here)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:394: error: `SIC_COMPLEX'

   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:400: error: `
   SCRIPT_CONTROL' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:400: error: `control'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:401: error: `SCRIPT_STATE
   ' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:401: error: `state'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:405: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:406: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:413: error: `SCRIPT_ITEM'

   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:413: error: `items'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:413: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:415: error: `
   ScriptItemize' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:417: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:424: warning: initializati
on
    to `int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:424: warning: argument to

   `int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:427: error: `
   SCRIPT_VISATTR' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:427: error: `attr'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:427: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:466: error: `
   SCRIPT_UNDEFINED' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:468: error: `ScriptCache'

   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:470: error: `
   ScriptGetCMap' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:474: error: `
   SCRIPT_FONTPROPERTIES' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:474: error: syntax error
   before `;' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:475: error: `
   scriptProperties' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:475: error: `
   ScriptGetFontProperties' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:490: error: `ScriptShape'

   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:494: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:506: error: `
   USP_E_SCRIPT_NOT_IN_FONT' undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:507: warning: comparison
   between signed and unsigned integer expressions
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:526: warning: comparison
   between signed and unsigned integer expressions
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:556: error: `GOFFSET'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:556: error: `offsets'
   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:556: error: syntax error
   before `)' token
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:564: error: `ScriptPlace'

   undeclared (first use this function)
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:575: warning: assignment
   to `PRInt32' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:575: warning: argument to

   `int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:600: warning: comparison
   between signed and unsigned integer expressions
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:608: warning: comparison
   between signed and unsigned integer expressions
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:599: warning: unused
   variable `int lookForOpp'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:630: warning: assignment
   to `PRInt32' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:630: warning: argument to

   `int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:634: warning: assignment
   to `PRInt32' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:634: warning: argument to

   `int' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:681: warning: assignment
   to `PRInt32' from `double'
c:/mozilla/mozilla/gfx/thebes/src/gfxWindowsFonts.cpp:681: warning: argument to

   `int' from `double'
make[3]: *** [gfxWindowsFonts.o] Error 1
make[3]: Leaving directory `/cygdrive/c/mozilla/mozilla/gfx/thebes/src'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/cygdrive/c/mozilla/mozilla/gfx/thebes'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `/cygdrive/c/mozilla/mozilla/gfx'
make: *** [all] Error 2

So now Usp10.h is missing, apparently.
One problem is that cygwin/MinGW doesn't have a mlang.h
Blocks: mingw
GCC chokes on the present declaration of one of the |gfxWindowsFonts| constructors, leading to yet another build error (after avoiding the issues of MLang.h and usp10.h).  This error is fixed by the attached patch.
Attachment #213194 - Flags: review?(vladimir)
The major problem introduced with the fix for Bug 324560 is that "Uniscribe" support is now required (usp10.h, usp10.dll).
Apparently, abiword had a similar problem almost two years ago,
http://sourceforge.net/tracker/?group_id=2435&atid=102435&func=detail&aid=921050

Looking at the source code (abiword-2.4.2), it becomes apparent that abiword does not link against usp10.dll but loads this dll dynamically.  Namely, in abi/src/af/gr/win/gr_Win32USPGraphics.h it is stated that 
    // IMPORTANT: All uniscribe functions must be called via these
    // pointers since we do not want to link against usp10.dll !!!

This implies that linking against usp10.dll (as it is now done in mozilla), might not be a good idea.
Depends on: 324560
From my reading it seems to get worse. "Uniscribe" is shipped with IE >= 5 and/or Win32 >= Win2k.
(In reply to comment #6)
> From my reading it seems to get worse. "Uniscribe" is shipped with IE >= 5
> and/or Win32 >= Win2k.

Yes, Win2k is the minimum supported windows version (Platform SDK and runtime) on the trunk.

I was under the impression that Windows 95 was the minimum version.

However, I do see at http://www.mozilla.com/firefox/system-requirements.html that Windows 98 is stated as the minimum.
(In reply to comment #8)
> I was under the impression that Windows 95 was the minimum version.
> 
> However, I do see at http://www.mozilla.com/firefox/system-requirements.html
> that Windows 98 is stated as the minimum.

Yes, Windows 98 (and probably 95) is the minimum for the current shipping version of firefox, which is what that page reflects.  For the Trunk, which will be the basis of a future version of Firefox, the minimum is now Win2k.


OK, well in that case I'd better start warning people that they have to upgrade their Win98, Win98SE, WinME boxes to WinXP Pro (not Home as MS stops supporting that this year) or they will not be able to use the latest Firefox.

However, that doesn't help with the issue surrounding mlang.h and usp10.h
(In reply to comment #10)
> OK, well in that case I'd better start warning people that they have to upgrade
> their Win98, Win98SE, WinME boxes to WinXP Pro (not Home as MS stops supporting
> that this year) or they will not be able to use the latest Firefox.

Win98's end-of-life is June of this year.  "The latest Firefox" will continue to run fine on win98 probably until the early half of next year, and Firefox 2 will continue to run fine on win98 indefinitely.

> However, that doesn't help with the issue surrounding mlang.h and usp10.h

True; for those issues, the problem is mingw's lack of headers; there's nothing we can do.

(In reply to comment #11)
> (In reply to comment #10)
> > However, that doesn't help with the issue surrounding mlang.h and usp10.h
> 
> True; for those issues, the problem is mingw's lack of headers; there's nothing
> we can do.
> 
on mingw, one should in theory be able to steal the wine headers (http://www.winehq.org/). It should work with little or no tweaks.
True, wine has them. I also found them in the Microsoft Platform SDK which is freely available from Microsoft.

Still trying to persuade it to build....
(In reply to comment #13)
> True, wine has them. I also found them in the Microsoft Platform SDK which is
> freely available from Microsoft.
> 
> Still trying to persuade it to build....
> 
If you are having trouble linking, you can try buiding wine under mingw (it will provide the import libs)
Summary: Mingw build error in gfxWindowsPlatform.h → Mingw build error in gfxWindowsPlatform.h (require MLang.h and usp10.h)
Blocks: 311993
checked in
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
This bug isn't fixed. The patch just fixed one build error.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
i'm not really sure what else to do to fix this bug then.  you're going to need to find mlang.h and usp10.h headers or move to vc8..
Blocks: msys
(In reply to comment #17)
> i'm not really sure what else to do to fix this bug then.  you're going to need
> to find mlang.h and usp10.h headers or move to vc8..
> 
I had to update my platform SDK and add its Include directory to my environment to get a clean build with MSVC/MSYS. Certainly caught me off guard.
so everything builds with an updated platform sdk?
I don't thinkg that's the case for mingw.
I can confirm it does not build on MinGW. I get exactly the same errors as were described here. So what do we do? I do not like to rely upon VC8 exclusively or borrowing (stealing?) some headers from it. After all MinGW is free and VC8 is not.
I'd say we have to find a workaround.

BE 
I made some further experiments with mlang.h and usp10.h placed in 
/mozilla/mingw/include, and also updated my Mingw to the latest available version dated jan 2006. This was the result:

/cygdrive/d/mozilla/mozilla/build/cygwin-wrapper g++ -mno-cygwin -shared -Wl,--o
ut-implib -Wl,libthebes.dll.a -o thebes.dll  gfxContext.o gfxImageSurface.o gfxP
attern.o gfxFont.o gfxPlatform.o gfxWindowsFonts.o gfxWindowsPlatform.o gfxWindo
wsSurface.o   ./module.res    -Wl,--whole-archive ../../../dist/lib/libmozcairo.a ../../../dist/lib/libmozlibpixman.a  -Wl,--no-whole-archive -L../../../dist/lib -lnspr4 -lplc4 -lplds4 -L../../../dist/lib -lxpcom -lxpcom_core  -lm  -lusp10
 -lole32

d:\mozilla\mingw\bin\..\lib\gcc\mingw32\3.4.5\..\..\..\..\mingw32\bin\ld.exe: cannot find -lusp10

collect2: ld returned 1 exit status

make[6]: *** [thebes.dll] Error 1

make[6]: Leaving directory `/cygdrive/d/mozilla/mozilla/gfx/thebes/src'

make[5]: *** [libs] Error 2

make[5]: Leaving directory `/cygdrive/d/mozilla/mozilla/gfx/thebes'

make[4]: *** [libs] Error 2

make[4]: Leaving directory `/cygdrive/d/mozilla/mozilla/gfx'

make[3]: *** [libs_tier_9] Error 2

make[3]: Leaving directory `/cygdrive/d/mozilla/mozilla'

make[2]: *** [tier_9] Error 2

make[2]: Leaving directory `/cygdrive/d/mozilla/mozilla'

make[1]: *** [default] Error 2

make[1]: Leaving directory `/cygdrive/d/mozilla/mozilla'

make: *** [build] Error 2

it looks like the parameter -lusp10 is not recognized


no, that just means that mingw doesn't have the uniscribe import library.
(In reply to comment #22)
I think that's bug 311993.

(In reply to comment #21)
> I'd say we have to find a workaround.
One workaround is to disable cairo for mingw. Add this into your .mozconfig:
ac_add_options --disable-svg
ac_add_options --enable-default-toolkit=windows
ac_add_options --disable-canvas
You could encounter bug 328951, in that case.

Windows Platform SDK (e.g. version 3790.1830) contains the files MLang.h and usp10.h (Include directory) and USP10.Lib (Lib directory).  But even if this helps to build, it not really solves the main problem, because it would generate an undesired dependency on the Platform SDK.
(In reply to comments #24 and #25)

I agree, even if using the headers and libs from Windows Platform SDK would help,     (it does not, more errors will appear, all related to gfx), we would create an unwanted dependancy. 
I wonder if anyone out there has succeded - with the current source - to build with Mingw?
*** Bug 330253 has been marked as a duplicate of this bug. ***
isn't this a blocker? mingw cant be built due to this issue
(In reply to comment #28)
> isn't this a blocker? mingw cant be built due to this issue

mingw is not a supported platform.

"It is also possible (but not recommended) to compile Mozilla using the mingw gcc compiler"
This is what it is said in the Windows Build Prerequisites.
In my world it is supported (but not recommended)

The same goes in principle for the Visual C++ Express Edition (Free VC8), there are quite some tweaks needed and in spite of that some options need to be switched off in Mozilla.

Maybe Henrik Gemal who wrote a very good paper on how to use mingw can be at help. 

 


(In reply to comment #30)
> Maybe Henrik Gemal who wrote a very good paper on how to use mingw can be at
> help. 

Sorry. No can do.

(In reply to comment #29)
> mingw is not a supported platform.

Officially, it *is* supported (as a tier-3 platforms), but (regarding comment 28 and comment 30) it is not a blocker - only tier-1 platforms qualify for this; even tier-2 platforms (ports) don't qualify as blockers.

http://developer.mozilla.org/en/docs/Mozilla_Build_FAQ#General_questions
The definition of "supported" is not very clear: the various tiers indicate different levels of support:

tier-1: if a checkin breaks these platforms, the developer is responsible for backint out immediately or the tree needs to be closed

tier-2: if a checkin breaks these platforms, the developer is responsible for investigating and fixing, but it doesn't have to be immediately and the tree doesn't need closure

tier-3: broken trees are the responsibility of the port maintainer: developers are not required to spend time fixing the problem.
Here's a patch that makes the mingw build work with the thebes (and whatever else) landing.  The cross-compiled binary builds run on my win32 box. Some of these fixes apply to bugs that were filed separately (search for mingw in the subject). Someone else will have to drive getting these changes into the tree.

* Unconditionally define MOZ_DISABLE_MLANG_SUPPORT & MOZ_DISABLE_UNISCRIBE_SUPPORT when building with win32-gcc
* Add NS_THEBES define to use the old dllimport/dllexport pair for gfxPattern to avoid the auto-import issue with mingw ld
* cairo_public should use dllexport on all XP_WIN platforms
* libthebes is a dynamic lib so don't attempt to link it into libgkwidget as a SHARED_LIBRARY_LIB
* OPENFILENAME_SIZE_VERSION_400 isn't defined for mingw
* Neither are the IMR_* defines
* IME* isn't (completely?) defined
disabling mlang and uniscribe produces builds that won't be able to render any complex scripts and puts a big mess in the code.  I don't want to deal with the follow up bugs "can't do xxx with mingw builds"

the right fix here seems to be to get some real platform sdk or move to vc 8 express.
(In reply to comment #35)
> disabling mlang and uniscribe produces builds that won't be able to render any
> complex scripts and puts a big mess in the code.  I don't want to deal with the
> follow up bugs "can't do xxx with mingw builds"
> 
> the right fix here seems to be to get some real platform sdk or move to vc 8
> express.
> 

I'm not averse to adding the required mlang and usp10 support to MinGW, if anyone would like to contribute appropriate patches; see:
http://www.mingw.org/MinGWiki/index.php/SubmitPatches

Do please note that I will not accept any patches which copy from Microsoft's Platform SDK;  while that may be freely available, it isn't free to use or distribute, and I'm not going to infringe Microsoft's copyright.
(In reply to comment #34)
> Created an attachment (id=215685) [edit]
> fix mingw build issues
> 

Hmmm it doesn't seem to work on my mingw build. I still get the mlang.h missing error.
Do I need to add something to .mozconfig?
Gemal, the patch contains a change to configure.in so you need to run autoconf-2.13 after applying the patch.

Pavlov, what's a "complex script"?  How is this reduced feature set of the mingw build any different than the accessiblity, activex, IE profile migrator, etc features that the mingw build has been doing without for years for the exact same reasons?  Not to mention WINCE which also has a reduced feature set IIRC.  

I understand wanting to minimize an "unsupported" port's impact on your development but from the little that you've said, I'm not convinced that the impact should be that great since as bsmedberg pointed out, the responsibility is on the port developers to actually provide fixes.  However, reviewing the fixes comes with module owner responsibility so the port isn't for zero cost.  If m.o does decide to drop mingw (as is), please let people know rather than just letting things rot.

It's non-zero cost beyond reviews simply because of having to deal with a myriad of ifdefs and similar in the code.  There's another patch that rips out support for win98/ME -- and it does so by removing a ton of crufty code, leaving the rest much simpler to understand and to maintain.
Depends on: 331287
Currently, I am working on MinGW patches that implement the required interfaces and provide the needed import libraries.  Chris Seawood's patch (Comment 34) is very helpful as a roadmap.
(In reply to comment #38)
> Gemal, the patch contains a change to configure.in so you need to run
> autoconf-2.13 after applying the patch.
> 

Thanx. I got Firefox builed now.
(In reply to comment #40)
> Currently, I am working on MinGW patches that implement the required interfaces
> and provide the needed import libraries.  Chris Seawood's patch (Comment 34) is
> very helpful as a roadmap.
> 

Now the man is talking...Thank you, looking forward to your results.
Depends on: 328951
Depends on: 331329
Depends on: 331333
Status: REOPENED → ASSIGNED
Assignee: nobody → engel
Status: ASSIGNED → NEW
Firefox now builds fine with MinGW !!
Thebes also works with MinGW !!

This requires the following three trivial patches to mozilla, https://bugzilla.mozilla.org/buglist.cgi?bug_id=331287,331329,331333. (Hopefully they will be timely reviewed.)

However, I also needed to implement some lengthy extension of MinGW--including implementing the MLang and the Uniscribe APIs.  This is now done and the patches are submitted, please see
http://sourceforge.net/tracker/index.php?func=detail&aid=1456654&group_id=2435&atid=302435
http://sourceforge.net/tracker/index.php?func=detail&aid=1456650&group_id=2435&atid=302435
http://sourceforge.net/tracker/index.php?func=detail&aid=1456401&group_id=2435&atid=302435
http://sourceforge.net/tracker/index.php?func=detail&aid=1456159&group_id=2435&atid=302435
http://sourceforge.net/tracker/index.php?func=detail&aid=1456122&group_id=2435&atid=302435
http://sourceforge.net/tracker/index.php?func=detail&aid=1455684&group_id=2435&atid=302435
   Before these patches are committed to the MinGW CVS, I can email the required files (including libusp10.a) to interested people.
Status: NEW → ASSIGNED
Summary: Mingw build error in gfxWindowsPlatform.h (require MLang.h and usp10.h) → Mingw build error in gfxWindowsPlatform.h (need to update mingw with mlang.h and usp10.h)
Fantastic work, Hans-Andreas!
But it means that when the mingw patches are accepted and checked in, one has to upgrade to the latest cvs version, right?
Blocks: 330383
Cleaning up dependencies: regressions should block the original bug, not the other way around, and this and bug 294122 are unrelated; the msys vs cygwin question is independent of what compiler is being used.

Also, retitling to reflect this bug's movement toward the more general issue.

Please correct me if I've missed anything.  Also, in the future, please file separate metabugs instead of taking over a bug about a specific issue.

Sorry if I sound nitpicky; there's some great work going on in this bug, so thanks for putting in the effort.
Blocks: 324560
No longer blocks: msys
No longer depends on: 324560
Summary: Mingw build error in gfxWindowsPlatform.h (need to update mingw with mlang.h and usp10.h) → Mingw build errors building cairo-windows (patches needed for both Mozilla and MinGW)
Thank you for your clarifications and for cleaning up dependencies!
   Actually, this bug bases on specific issues relating to mlang.h and usp10.h headers (see description and Comment 1) and on discussions if we should ifdef the dependence on these APIs---so it seems to me that this bug was not too much "misused."
   Note that related issues and corresponding mozilla patches were filed to separate bugs (see dependency list) and that a meta bug is already available (Bug 203303).

The MinGW patches will be reviewed soon, and I will post important progress here (as this again concerns the mlang.h and usp10.h headers).
Summary: Mingw build errors building cairo-windows (patches needed for both Mozilla and MinGW) → Mingw build errors building cairo-windows (need to apply patches to MinGW; including mlang.h and usp10.h)
Many Thanks to Danny Smith for a very timely review of the patches to MinGW's w32api!  All patches mentioned in Comment 43 are now checked in; so we only have to wait for the fixes in the bug this one depends on before we can close this bug.  

Chris Seawood's patch additionaly contains the interesting idea to allow switching off dependency on the Uniscribe Library [although  Vladimir Vukicevic does not like this due to the added ifdefs (Comment 39)].  I suggest to move this idea to a different bug (if people still are interested in it), as an alternative solution for this bug has now been implemented.
To install the latest w32api from MinGW fresh from the CVS, just run the following commands in cywin.

cvs -d:pserver:anonymous@www.sourceware.org:/cvs/src login
[arbitrary password]
cvs -d:pserver:anonymous@www.sourceware.org:/cvs/src checkout src/winsup/w32api/
cd src/winsup/w32api/
./configure
make install

If you are using msys, you should rather use
  ./configure --includedir=/mingw/include  --libdir=/mingw/lib
I apologize for the verbosity of this entry. Now, I am running into the error...
<i>
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp: In function `BOOL nsGetFileVersionInfoW(const WCHAR*, DWORD, DWORD, void*)':
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp:235: error: invalid conversion from `const char*' to `CHAR*'
</i>

<b>STEPS to reproduce follow</b>
<b>1.</b>checked updated w32api from MinGW. 
<b>2.</b>Performed make.
<b>3.</b>After running make, I copied 'include' and 'lib' folders into my existing c:\mozilla\mingw folder.
<b>4.</b>I did a fresh checkout yesterday morning.
<b>5.</b>Ran my environment setup bat file 
<i>
set CYGWINBASE=c:\cygwin
set MOZ_TOOLS=c:\mozilla\moztools
set MSSDK=c:\mozilla\MS_PSDK
set HOME=c:\mozilla
set PATH=%MSDK%\bin;%HOME%\mingw\bin;%CYGWINBASE%;%CYGWINBASE%\bin;%MOZ_TOOLS%\bin;%PATH%
set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:\cvsroot
set INCLUDE=%HOME%\mingw\include;%MSSDK%\Include;%MOZ_TOOLS%\include;%MOZ_TOOLS%\include\libIDL;%INCLUDE%;
set LIB=%MSDK%\lib;%LIB%
</i>
<b>6.</b>Opened cygwin shell. And ran the following make...
<i>make -f client.mk build_all > $HOME/mozilla/build_new_mingw1.log 2>&1</i>
<b>7.</b>Here is my mzconfig....
<i>. /cygdrive/c/mozilla/mozilla/browser/config/mozconfig_browser
CC=gcc
CXX=g++
CPP=cpp
AS=as
LD=ld
LDFLAGS="-mwindows -Wl,--enable-runtime-pseudo-reloc"
ac_add_options --enable-debug
ac_add_options --disable-optimize
mk_add_options MOZ_OBJDIR=/cygdrive/c/mozilla/build_new_mingw
ac_add_options --disable-tests
ac_add_options --disable-crypto
ac_add_options --disable-activex
ac_add_options --disable-activex-scripting
ac_add_options --disable-xpconnect-idispatch 
ac_add_options --disable-accessibility       
</i>
<b>8.</b>i ran into the following error. 
<i>make[5]: Entering directory `/cygdrive/c/mozilla/build_new_mingw/xpcom/io'
nsWinAPIs.cpp
Building deps for /cygdrive/c/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp
/cygdrive/c/mozilla/mozilla/build/cygwin-wrapper g++ -mno-cygwin -o nsWinAPIs.o -c  -DMOZILLA_INTERNAL_API -DOSTYPE=\"WINNT5.1\" -DOSARCH=\"WINNT\" -DBUILD_ID=0000000000 -D_IMPL_NS_COM -I.. -I../../dist/include/string -I../../dist/include   -I../../dist/include/xpcom -I../../dist/include/nspr    -I/usr/X11R6/include     -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -mms-bitfields -pipe  -DDEBUG -D_DEBUG -DDEBUG_Mpitts -DTRACING -g  -I/usr/X11R6/include -DWINVER=0x500 -D_WIN32_WINNT=0x500 -DMOZILLA_VERSION=\"1.9a1\" -DMOZILLA_VERSION_U=1.9a1 -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -D_WIN32=1 -DWIN32=1 -DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DSTDC_HEADERS=1 -DWIN32_LEAN_AND_MEAN=1 -DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DHAVE_GETOPT_H=1 -DHAVE_MEMORY_H=1 -DHAVE_UNISTD_H=1 -DHAVE_MALLOC_H=1 -DHAVE_X11_XKBLIB_H=1 -DHAVE_LIBM=1 -DNO_X11=1 -DMMAP_MISSES_WRITES=1 -DHAVE_STRERROR=1 -DHAVE_SNPRINTF=1 -DHAVE_MEMMOVE=1 -DHAVE_RINT=1 -DVA_COPY=va_copy -DHAVE_VA_COPY=1 -DMOZ_DEFAULT_TOOLKIT=\"cairo-windows\" -DMOZ_THEBES=1 -DMOZ_CAIRO_GFX=1 -DMOZ_PHOENIX=1 -DMOZ_BUILD_APP=browser -DMOZ_XUL_APP=1 -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DMOZ_XPINSTALL=1 -DMOZ_JSLOADER=1 -DNS_PRINTING=1 -DNS_PRINT_PREVIEW=1 -DMOZ_XTF=1 -DMOZ_MATHML=1 -DMOZ_ENABLE_CANVAS=1 -DMOZ_SVG=1 -DMOZ_SVG_FOREIGNOBJECT=1 -DMOZ_UPDATE_CHANNEL=default -DMOZ_PLACES=1 -DMOZ_STORAGE=1 -DMOZ_LOGGING=1 -DDETECT_WEBSHELL_LEAKS=1 -DHAVE___CXA_DEMANGLE=1 -DMOZ_DEMANGLE_SYMBOLS=1 -DMOZ_USER_DIR=\"Mozilla\" -DHAVE_STDINT_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_UINT64_T=1 -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DMOZ_MORKREADER=1 -DMOZ_DLL_SUFFIX=\".dll\" -DJS_THREADSAFE=1 -DMOZ_REFLOW_PERF=1 -DMOZ_REFLOW_PERF_DSP=1 -DMOZILLA_LOCALE_VERSION=\"1.9a1\" -DMOZILLA_REGION_VERSION=\"1.9a1\" -DMOZILLA_SKIN_VERSION=\"1.8\"  -D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT /cygdrive/c/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp: In function `BOOL nsGetFileVersionInfoW(const WCHAR*, DWORD, DWORD, void*)':
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp:235: error: invalid conversion from `const char*' to `CHAR*'
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp: In function `DWORD nsGetFileVersionInfoSizeW(const WCHAR*, DWORD*)':
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp:243: error: invalid conversion from `const char*' to `CHAR*'
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp: At global scope:
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp:552: error: invalid conversion from `BOOL (*)(WCHAR*, DWORD, DWORD, void*)' to `BOOL (*)(const WCHAR*, DWORD, DWORD, void*)'
c:/mozilla/mozilla/xpcom/io/nsWinAPIs.cpp:553: error: invalid conversion from `DWORD (*)(WCHAR*, DWORD*)' to `DWORD (*)(const WCHAR*, DWORD*)'
make[5]: *** [nsWinAPIs.o] Error 1
make[5]: Leaving directory `/cygdrive/c/mozilla/build_new_mingw/xpcom/io'
</i>
Please advise.


Mark, thank you for your comment.  This build problem is in a quite different location of the code, so it probably does not belong here (i.e., file a new bug for new problems).

However, I think that there is an easy explanation for your error: it seems that you have not updated all headers mentioned in Comment 43.  Probably it is easiest to just pull the recent version from the MinGW CVS.  See also in  https://bugzilla.mozilla.org/show_bug.cgi?id=162361#c156
Are the "three trivial patches to mozilla", see comment #43, yet checked in? I thought these were necessary for a successful build with Mingw.
The xpcom/io bustage is due to the checkin for bug 162361.
The mozilla build system fixes are now checked in, thanks Stuart.  Closing this bug.

How the MinGW problems can be fixed (pulling mlang.h and usp10.h from the MinGW CVS) is explained in Comment 48.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
Strange, I got exactly the build error in comment 49, but this was with the "fix mingw bustage v1" patch from bug 162361, comment 165.
After I backed that patch out xpcom would build again.
I've done the mingw update directions as mentioned in comment 48.
I am still struggling with getting this build to work,
despite having applied all necessary fixes as per 
commt # 43

I think my shortcoming relates to the the setup steps
I followed (see my original comment # 49 for a description of my setup).

I verified that mlang.h now exists under c:\mozilla\mingw\include.
I can see that mingw/include is NOT included in the list of include
folders (partial output included). 

Can someone advise how I can ensure that the mingw/include
folder will get picked up?

Building deps for
/cygdrive/c/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp
/cygdrive/c/mozilla/mozilla/build/cygwin-wrapper g++
-mno-cygwin -o gfxPlatform.o -c 
-DMOZILLA_INTERNAL_API -DOSTYPE=\"WINNT5.1\"
-DOSARCH=\"WINNT\" -DBUILD_ID=0000000000 
-I../../../dist/include/cairo
-I../../../dist/include/libpixman
-I../../../dist/include/string
-I../../../dist/include/pref
-I../../../dist/include/xpcom -I../../../dist/include 
 -I../../../dist/include/thebes
-I../../../dist/include/nspr   
-I../../../dist/sdk/include -I/usr/X11R6/include    
-I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall
...
...
-I../../../dist/include/cairo  
-I/usr/X11R6/include -DWINVER=0x500
...
...
-D_MOZILLA_CONFIG_H_ -DMOZILLA_CLIENT
/cygdrive/c/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp
In file included from
c:/mozilla/mozilla/gfx/thebes/src/gfxPlatform.cpp:41:
../../../dist/include/thebes/gfxWindowsPlatform.h:47:19:
mlang.h: No such file or directory
With the updated MinGW, the "fix mingw bustage v1" kludge mentioned in the Comment 54 is not needed, as the relevant functions are now properly declared in MinGW (see another comment: bug 162361, Comment 156).
Mark Pitts, I am not sure that you have installed the MinGW headers in the right place.  They should be in /usr/include/w32api, as you are using cygwin (for msys, they would be in /mingw/include).

So I would like to suggest that (a) you check that you have the updated headers in the directory /usr/include/w32api, and that (b) you remove all the other MinGW headers floating around (as this might lead to confusions later on).
Whiteboard: See Comment 48 for instructions how to easily update MinGW from CVS
The original file I downloaded from mingw.org, w32api-3.6.tar.gz, does not contain include/w32api. Nor does the code checked out from sourceforge, as per comment #48. So far, I have kept mingw files, including w32api, separate from my cygwin installation. 
So now I am a little at a loss. Shall I copy all header files from  the location , as specified in comment # 48, into my cygwin/include/w32api folder? What about the compiled (.o) binaries created after running make install (as specified in comment # 48). 
Downloading the files from the MinGW CVS is the first part (note that version 3.6 is too old, it must be CVS or a newer version), installing them in the right location the second.

In Cygwin, it should be sufficient to go the the downloaded "w32api" directory and to run the following command (cf. Comment 48)
   ./configure && make install

If this does not work for you, I can also send you the required files directly, feel free to contact me via email.
Concretely, you need the following files when compiling with cywin.  You can copy these files by hand from the include and the lib directories after downloading and compiling MinGW's w32api.  ("make install" should do this automatically for you, have a close look at the build output.)

/usr/include/w32api/commdlg.h
/usr/include/w32api/imm.h
/usr/include/w32api/mlang.h
/usr/include/w32api/usp10.h
/usr/include/w32api/winver.h
/usr/lib/w32api/libusp10.a
/usr/lib/w32api/libuuid.a
Martijn pointed out to me that the build instructions in
http://gemal.dk/mozilla/build.html suggest to use the MinGW gcc compiler (not the one from cygwin), i.e., the same compiler that is used in msys.  Consequently, the files need to be placed as /mingw/include/mlang.h and /mingw/lib/libusp10.a etc. 

Thus, when installing from CVS, one should use (as for msys)
   ./configure --includedir=/mingw/include  --libdir=/mingw/lib
   make install
Note that w32api version 3.7 is out, which has everything needed to build Mozilla.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: