| 1 | ------------------------------------------------------------------------ |
| 2 | How to build the sources from CVS |
| 3 | ------------------------------------------------------------------------ |
| 4 | |
| 5 | Please use the install.txt files in docs/gtk, docs/msw, docs/motif, docs/mac |
| 6 | etc. alongside these instructions. |
| 7 | |
| 8 | I) Windows using plain makefiles |
| 9 | ---------------------------------------- |
| 10 | |
| 11 | a) If using Microsoft Visual C++ 5.0 or 6.0 |
| 12 | |
| 13 | Ensure that the command-line compiler and tools (including |
| 14 | nmake) are installed and ready to run. Depending on your |
| 15 | installation there may be a batch file (named something like |
| 16 | VCVARS32.BAT) that needs to be run to set correct environment |
| 17 | varaibles and PATH entries. |
| 18 | |
| 19 | Continue with item c) below. |
| 20 | |
| 21 | |
| 22 | b) If using the GNU Mingw32 or GNU Cygwin32 compilers |
| 23 | |
| 24 | You can get Mingw32 from http://www.mingw.org |
| 25 | |
| 26 | Cygwin32 is available at http://www.cygwin.com |
| 27 | |
| 28 | The makefile might have small problems with Cygwin's tools |
| 29 | so it is recommended to use Mingw32 and its toolchain instead |
| 30 | if possible. |
| 31 | |
| 32 | -> Set your path so that it includes the directory |
| 33 | where your compiler and tools reside |
| 34 | |
| 35 | -> If your are using an old Mingw32 version (gcc-2.95 or older), |
| 36 | you might need to fix some headers with the patches contained |
| 37 | in the wxWin\Mingw32-gcc295.patches file. PLEASE APPLY THESE |
| 38 | PATCHES BY HAND! There are apparently a few different versions |
| 39 | of the headers floating around. Note that these patches are |
| 40 | not needed if you are using Mingw32 gcc-2.95.2 or newer. |
| 41 | |
| 42 | -> Edit wx/src/makeg95.env and set the MINGW32 variable at the top of |
| 43 | the file to either 1 (you have Mingw32) or 0 (you have Cygwin32). |
| 44 | If using MINGW32, also set the MINGW32VERSION variable |
| 45 | appropiately. |
| 46 | |
| 47 | |
| 48 | c) Build instructions |
| 49 | |
| 50 | -> Assumming that you installed the wxWindows sources |
| 51 | into c:\wxWin |
| 52 | -> Copy c:\wxWin\include\wx\msw\setup0.h |
| 53 | to c:\wxWin\include\wx\msw\setup.h |
| 54 | -> Edit c:\wxWin\include\wx\msw\setup.h so that |
| 55 | most features are enabled (i.e. defined to 1), for example: |
| 56 | #define wxUSE_ODBC 0 |
| 57 | #define wxUSE_SOCKETS 1 |
| 58 | #define wxUSE_HTML 1 |
| 59 | #define wxUSE_THREADS 1 |
| 60 | #define wxUSE_FS_INET 0 |
| 61 | #define wxUSE_FS_ZIP 1 |
| 62 | #define wxUSE_BUSYINFO 1 |
| 63 | #define wxUSE_DYNLIB_CLASS 1 |
| 64 | #define wxUSE_ZIPSTREAM 1 |
| 65 | #define wxUSE_LIBJPEG 1 |
| 66 | #define wxUSE_LIBPNG 1 |
| 67 | |
| 68 | and std iostreams are disabled with |
| 69 | #define wxUSE_STD_IOSTREAM 0 |
| 70 | |
| 71 | -> type: cd c:\wxWin\src\msw |
| 72 | -> type: make -f makefile.g95 (if using GNU tools) |
| 73 | or type: nmake -f makefile.vc (if using MS VC++) |
| 74 | |
| 75 | |
| 76 | II) Unix ports |
| 77 | -------------- |
| 78 | |
| 79 | Building wxGTK or wxMotif completely without configure |
| 80 | won't ever work, but there is now a new makefile system |
| 81 | that works without libtool and automake, using only |
| 82 | configure to create what is needed. |
| 83 | |
| 84 | In order to create configure, you need to have the |
| 85 | GNU autoconf package (version 2.13 or 2.14) installed |
| 86 | on your system and type run "autoconf" in the base |
| 87 | directory (or run the autogen.sh script in the same |
| 88 | directory, which just calls autoconf). |
| 89 | |
| 90 | Set WXWIN environment variable to the base directory such |
| 91 | as ~/wxWindows (this is actually not really needed). |
| 92 | |
| 93 | -> type: export WXWIN=~/wxWindows |
| 94 | -> type: md mybuild |
| 95 | -> type: cd mybuild |
| 96 | -> type: ../configure --with-motif |
| 97 | or type: ../configure --with-gtk |
| 98 | -> type: make |
| 99 | -> type: su <type root password> |
| 100 | -> type: make install |
| 101 | -> type: ldconfig |
| 102 | -> type: exit |
| 103 | |
| 104 | Call configure with --disable-shared to create a static |
| 105 | library. Calling "make uninstall" will remove the installed |
| 106 | library and "make dist" will create a distribution (not |
| 107 | yet complete). |
| 108 | |
| 109 | III) Windows using configure |
| 110 | ---------------------------------------- |
| 111 | |
| 112 | Take a look at Unix->Windows cross compiling. With minor |
| 113 | modifications, this should work in Windows if you've got the cygnus |
| 114 | utilities (bash, GNU make, etc) and either mingw32 or cygwin32 installed. |
| 115 | See http://www.cygnus.com for these programs, or go straight to their |
| 116 | ftp server at ftp://sourceware.cygnus.com/pub/cygwin/. |
| 117 | |
| 118 | Of course, you can also build the library using plain makefiles (see |
| 119 | section I). |
| 120 | |
| 121 | IV) Classic MacOS using CodeWarrior (eg MacOS 8.x/9.x) |
| 122 | ---------------------------------------- |
| 123 | |
| 124 | Refer to the readme.txt and install.txt files in docs/mac to build |
| 125 | wxWindows under Classic Mac OS using CodeWarrior. |
| 126 | |
| 127 | If you are checking out the CVS sources using cvs under Mac OS X and |
| 128 | compiling under Classic Mac OS, make sure that all text files have a |
| 129 | Mac OS type of 'TEXT' otherwise CodeWarrior may ignore them. Checking |
| 130 | out the CVS sources using cvs under Mac OS X creates untyped files |
| 131 | which can lead to compialtion errors under CodeWarrior which are hard |
| 132 | to track down. |
| 133 | |
| 134 | V) MacOS X using configure and the Developer Tools |
| 135 | ---------------------------------------- |
| 136 | |
| 137 | You need to have the Developer Tools installed. If this is not the case, |
| 138 | you will need to register at the Apple Developer web site (this is a free |
| 139 | registration) in order to download the Developer Tools installer. |
| 140 | |
| 141 | In order to create configure, you need to have the |
| 142 | GNU autoconf package (version 2.13 or 2.14) installed |
| 143 | on your system and type run "autoconf" in the base |
| 144 | directory (or run the autogen.sh script in the same |
| 145 | directory, which just calls autoconf). |
| 146 | |
| 147 | -> type: mkdir macbuild |
| 148 | -> type: cd macbuild |
| 149 | -> type: ../configure --with-mac |
| 150 | or type: ../configure |
| 151 | -> type: make |
| 152 | |
| 153 | VI) OS/2 |
| 154 | ---------------------------------------- |
| 155 | |
| 156 | VII) Unix->Windows cross-compiling using configure |
| 157 | -------------------------------------------------- |
| 158 | |
| 159 | First you'll need a cross-compiler; linux glibc binaries of mingw32 and |
| 160 | cygwin32 (both based on egcs) can be found at |
| 161 | ftp://ftp.objsw.com/pub/crossgcc/linux-x-win32. Otherwise you can |
| 162 | compile one yourself. Check the relevant FAQs. |
| 163 | |
| 164 | [ A Note about cygwin32 and mingw32: the main difference is that cygwin32 |
| 165 | binaries are always linked against cygwin.dll. This dll encapsulates most |
| 166 | standard Unix C extensions, which is very handy if you're porting unix |
| 167 | software to windows. However, wxMSW doesn't need this, so mingw32 is |
| 168 | preferable if you write portable C(++). ] |
| 169 | |
| 170 | You might want to build both Unix and Windows binaries in the same source |
| 171 | tree; to do this make subdirs for each e.g. unix and win32. If you've |
| 172 | already build wxWindows in the main dir, do a 'make distclean' there, |
| 173 | otherwise configure will get confused. (In any case, read the section 'Unix |
| 174 | using configure' and make sure you're able to build a native wxWindows |
| 175 | library; cross-compiling errors can be pretty obscure and you'll want to be |
| 176 | sure that your configure setup is basically sound.) |
| 177 | |
| 178 | To cross compile the windows library, do |
| 179 | -> cd win32 |
| 180 | (or whatever you called it) |
| 181 | Now run configure. There are two ways to do this |
| 182 | -> ../configure --host=i586-mingw32 --build=i586-linux --with-mingw \ |
| 183 | --enable-dnd=no --without-odbc |
| 184 | where --build= should read whatever platform you're building on. Configure |
| 185 | will notice that build and host platforms differ, and automatically prepend |
| 186 | i586-mingw32- to gcc, ar, ld, etc (make sure they're in the PATH!). |
| 187 | The other way to run configure is by specifying the names of the binaries |
| 188 | yourself: |
| 189 | -> CC=i586-mingw32-gcc CXX=i586-mingw32-g++ RANLIB=i586-mingw32-ranlib \ |
| 190 | DLLTOOL=i586-mingw32-dlltool LD=i586-mingw32-ld NM=i586-mingw32-nm \ |
| 191 | ../configure --host=i586-mingw32 --with-mingw --enable-dnd=no |
| 192 | |
| 193 | (all assuming you're using mingw32) |
| 194 | Drag'n'drop is disabled because mingw32 lacks (AFAIK) OLE headers. |
| 195 | |
| 196 | [ Update: some new mingw32 versions now have a new set of windows header |
| 197 | files, which apparently can handle ole. Untested at the moment ] |
| 198 | |
| 199 | ODBC files don't compile as of 13.10.99 - may be this will be fixed by the |
| 200 | moment you're reading these lines. |
| 201 | |
| 202 | Configure will conclude that shared libraries are out of the question and |
| 203 | opt for a static one. I haven't looked into DLL creation yet. |
| 204 | |
| 205 | Type |
| 206 | -> make |
| 207 | and wait, wait, wait. Don't leave the room, because the minute you do there |
| 208 | will be a compile error :-) |
| 209 | |
| 210 | NB: you risk to get quite a few warnings about "ANSI C++ forbids implicit |
| 211 | conversion from 'void *'" in all places where va_arg macro is used. This |
| 212 | is due to a bug in (some versions of) mingw32 headers which may be |
| 213 | corrected by editing the file |
| 214 | |
| 215 | ${install_prefix}/lib/gcc-lib/i586-mingw32/egcs-2.91.57/include/stdarg.h |
| 216 | |
| 217 | (instead of egcs-2.91.57 you may have something different), searching for |
| 218 | the lines |
| 219 | |
| 220 | /* Define __gnuc_va_list. */ |
| 221 | |
| 222 | #ifndef __GNUC_VA_LIST |
| 223 | #define __GNUC_VA_LIST |
| 224 | #if defined(__svr4__) || defined(_AIX) || defined(_M_UNIX) || defined(__NetBSD__) |
| 225 | typedef char *__gnuc_va_list; |
| 226 | #else |
| 227 | typedef void *__gnuc_va_list; |
| 228 | #endif |
| 229 | #endif |
| 230 | |
| 231 | and adding "|| defined(_WIN32)" to the list of platforms on which |
| 232 | __gnuc_va_list is char *. |
| 233 | |
| 234 | If this is successful, you end up with a libwx_msw.a in win32/lib. Now try |
| 235 | building the minimal sample: |
| 236 | |
| 237 | -> cd samples/minimal |
| 238 | -> make |
| 239 | |
| 240 | and run it with wine, for example (or copy to a Windows box) |
| 241 | -> wine minimal.exe |
| 242 | |
| 243 | If all is well, do an install; from win32 |
| 244 | -> make install |
| 245 | |
| 246 | Native and cross-compiled installations can co-exist peacefully |
| 247 | (as long as their widget sets differ), except for wx-config. You might |
| 248 | want to rename the cross-compiled one to i586-mingw32-wx-config, or something. |
| 249 | |
| 250 | Cross-compiling TODO: |
| 251 | --------------------- |
| 252 | - resource compiling must be done manually for now (should/can we link the |
| 253 | default wx resources into libwx_msw.a?) [ No we can't; the linker won't |
| 254 | link it in... you have to supply an object file ] |
| 255 | - dynamic libraries |
| 256 | - static executables are HUGE -- there must be room for improvement. |
| 257 | |