Compiling the MFC using Winelib
boaz at moeg.org
Mon Jan 24 04:12:14 CST 2005
Dan Dennison wrote:
>Are there resources available beyond simple compilation tips to assist in
>the building of the MFC library under Winelib?
>dand at csun.edu
I have done it up here last year. I did not post any results because by
the time I finished they changed the winelib make system on me (move to
winegcc) and I could not find any time to update it. If you want that I
send you all the old system I can do that (Save the MFC source itself of
course). Here are some notes on my experience.
MFC was actually easy. At the end I had MFC compiled out of the box with
a trivial number of changes. The real changes are very few.
1. The "(...)" functions and C++. In msvc if a C++ object is passed to a
printf like function the object is Just put on the stack struct style
(all members pushed, so that, at the end, the exact struct layout is in
stack memory.) In gcc it will issue a WARRNING and core dump in runtime.
So in MFC all print("%s" ,aCStringObj) need change to printf("%s"
2. A very few "typename"s missing in templates. (MSVC7 MFC is better in
that but has other problems)
That's it, no real code change, and NO comment out of 4000 lines (Like
mentioned in wine documentation.)
The all secret is in the compiling Environment and the set of headers files:
3. Other than the pure MFC source files you will need other MS headers
from MSVC\Include and MSVC\crt\src Since they come with the same License
as MFC you can use them freely. (If you paid for your MSVC copy). Here
too I can send you the list of extra needed files. My List is old and
probably some are already not needed as wine catches up very fast. I did
not put these headers in the wine/Include but in an extra Include dir
that has lower precedence than wine/Include, so any headers missing from
wine are taken from msvc/include. (At first I took the all MSVC headers
set and winemaker them). Later I narrowed them down to as needed bases.
4. Some g++ headers need a special copy inside the wine tree and the
-system (I think that is the switch) use, so g++ does not try to find
any of its original headers. These are the "typeof" and other core C++
headers. And they need to be changed a bit mainly to be able to survive
with msvcrt wine headers, and to not reference any gcc originals. (This
step is mainly for STLPort and ATL see below). In general NONE of the
original GCC++ headers can be used. This is because:
5. Use the MBCS switch in wine. MFC is highly MBCS and I think even in
msvc on windows it will not compile with out it. (Perhaps UNICODE is
also good but I never got there) And with out mention you need to use
6. All these "Get off my neck and stop sucking my blood" GCC switches
must be used. Most of them are mentioned in wine documentation and/or
are default for winegcc, maybe a couple extra for C++ specific stuff.
7. Compile main ATL. The main ATL files (3 I think) are included in
MSVC6-SP5 version of MFC. If they compile your life is much easier. Here
as opposed to MFC there are more changes to do. (But it is only a few
files). See my post of one year ago on the wine-devel archives search
for "For compile of MFC and ATL". Attached are a couple of patches that
will make your life a bit easier when compiling ATL. Or maybe find an
MFC that does not use ATL (old versions did not)
8. To Makefile or not to Makefile, this is the Question? By far most of
the work is in the Makefile (and directory layout). You must decide if
you want a static lib or a dynamic fake C++ DLL. In some projects you
must have the later but it is harder to do, (and very slow on load
time). Than you need all your winebuild/winegcc flags just right.
(Depending on the type of lib you're building)
9. WARRNINGS. Try to eliminate any warnings because in G++ some warnings
are errors. (See above) See my Patches (above) on how to do that.
This is just what I remember probably it is only half of it. If we look
at 8, above, it is perhaps easier to do what Dimi always says. First
compile it on MinGW on windows than you can be sure your Makefiles are
good, than the winelib is 90% there. (I never did that so I'm not sure
what problems hide there). But for sure you will not have 2, and you
then know the file listing for 3. If you do go that rout than MinGW
project will also be happy with your paper as well as Wine.
Well good luck
More information about the wine-devel