If you are building for OS X (Darwin), use Apple's tools (gcc) and treat it as Unix.
Note: I use version 8 of CodeWarrior. I haven't tried this with earlier versions.
On MacOS, you will be concerned with two types of build: Classic and Carbon. I use Classic for maximum backwards compatibility and Carbon for MacOS 9.1 (9.2.2 recommended) or newer with CarbonLib 1.5 or newer. The Carbon build runs natively on OS X. If you are a seasoned Mac developer you will know all this.
You can select the various build options using a prefix file (under C/C++ Language settings). This is to do the equivalent of the -D command line options for most other compilers.
For Classic I build without large file support and without thread support. So, the prefix file contains:
For Carbon I build with large file and thread support. Note that a 'thread' to Apple is not the same as a thread to everyone else. Apple uses the term 'multitasking' or (worse still) 'multiprocessing' when it refers to pre-emptively scheduled threads. So the prefix file contains:
#define THREADSAFE 1
The other important thing to remember when making a Carbon executable is to include carb.r in your project (e.g. from MacOS Support/PowerPlant/PowerPlant Resources/carb.r)
The command line 'sqlite' utility builds using SIOUX. For this you need all the files except tclsqlite.c. You can build the TCL library as a separate exercise, but you will need to put tcl.h in your Access Paths (under User Paths). Note that, when you use this utility, any relative path names you give it are relative to the directory containing the executable, and you will need to use Mac paths (using colons), even with the Carbon build running under OS X.
The libraries you will need for the Classic build are:
The libraries you will need for the Carbon build are:
All these (except the standard .libs) are under MacOS Support/Universal/Libraries, and then under PPCLibraries and StubLibraries. The standard libraries are under MSL/MSL_C// MSL_MacOS/Lib/PPC.
If you are building a shared library, you will need a file sqlite.mcp.exp, containing the following:
sqlite_version sqlite_encoding sqlite_open sqlite_close sqlite_exec sqlite_last_insert_rowid sqlite_changes sqlite_error_string sqlite_interrupt sqlite_complete sqlite_busy_handler sqlite_busy_timeout sqlite_exec_printf sqlite_exec_vprintf sqlite_get_table_printf sqlite_get_table_vprintf sqlite_mprintf sqlite_freemem sqlite_libversion sqlite_libencoding sqlite_create_function sqlite_create_aggregate sqlite_function_type sqlite_set_result_string sqlite_set_result_int sqlite_set_result_double sqlite_set_result_error sqlite_user_data sqlite_aggregate_context sqlite_aggregate_count sqlite_open_aux_file
A couple of other settings I do:
- On PPC Target, Creator, I put SQLI. (I'm not sure if that's the correct thing to do, but files created by sqlite, have this as the creator and 'Document' as type')
- On PPC Processor, I put Struct Alignment as PowerPC, Target Processor as Generic PowerPC and Function alignment as 4.
- If you are building a shared library, on PPC linker, remove __start from Main (Entry Points). Also don't include shell.c in the build.
- On PPC PEF I set the fragment name to sqlite, or tclsqlite if I am building for TCL.
I hope this works for you. If you find out anything else useful, add it to this page.
Added on 08/25/03 by mau: these instructions are good, but there are a couple of extra steps that are needed in order to compile a Classic library that can be used on older versions of MacOS (8.1- 8.6). If you simply add the libraries in CW8.3 the executable or library created will not open in these older machines if you forget the following steps:
In the classic target, don't forget to highlight the following libraries and set them to IMPORT WEAK (open the project inspector and select the libraries in the project window to set this) InterfaceLib CarbonAccessors.o MathLib UnicodeConverter TextCommon
This will guarantee that your executable/library will load when used with OS8.1, since the InterfaceLib and other stubs were different (and you can not use Universal Interfaces 3.2 with CW 8). However in order to guarantee that the code will run without a type 3 error you need to make sure support for large files is disabled as well, since the LFS functions used by FileManager are only available in OS9 and later. The easy way to do this in CW is to create a file (name it classic.pfx.pch), with the following contents:
#define SQLITE_DISABLE_LFS 1
Save this file in the same directory of your project, and enter the file name in the Classic target settings window, LANGUAGE SETTINGS->C/C++ Language-> PREFIX FILE. Recompile, and you should be ok.