There are several routine steps
that everyone who is porting software to Darwin should know:
- Configure, Make, etc.
To configure under Darwin,
you usually have to type ./configure ppc.
- Add Users
Some programs require the addition of specific users, such as man,
news, games, cyrus, etc, in order to
install correctly. A variation of the net installer script is useful
for adding users.
Check it out, and adapt it to your needs. These users typically
do not require home directories, and ideally, nologin should be set
(or a very obscure passwd). Sometimes you can edit /etc/mtree/* to get
around this problem, but that does not work for every case.
- Shims
Occasionally, ports require the addition of shims (aka stubs),
which can be compiled into your program.
I have a shim collection at
http://www.gnu-darwin.org/shims/.
Some of these are terrible hacks or quite obsolete,
so if you have shims you would like to contribute, please do!
- Enabling pthread
Pthreading (POSIX threading) is good,
because it makes some programs go faster.
On Darwin, pthread does not reside in a library,
but is actually part of the operating system.
Certain programs don't recognize, however,
that Darwin has some pthread awareness.
There might be a line in the ./configure file
that reads something like this:
libs="-pthread"
Remove -pthread from that line.
When you configure, the program will say pthread... yes.
Later, you might run into problems,
because not all of the pthread calls are implemented yet.
If this happens, you can put -pthread back
in the ./configure file
and reconfigure without pthreading.
We can always turn pthreading back on
when the needed support is ready...
-
Repair libraries
If you get a message about an undefined symbol
(e.g., "/usr/bin/ld: Undefined symbols: __Xdebug"),
you can try the following procedure, but use care.
You don't want to mess up your libraries!
I sometimes use grep to test the archives,
but that is not actually the correct method.
Here it is anyway.
I'm sure that someone will clue me in at some point...
% grep __Xdebug /usr/X11R6/lib/*.a
Let's say it returns the result
"Binary file /usr/X11R6/lib/libX11.a matches",
suggesting that there might be something wrong with libX11.
If so, try this:
% su root
# ranlib -s /usr/X11R6/lib/libX11.a
or this:
# ranlib -c /usr/X11R6/lib/libX11.a
If those don't work, check the ar man page
for how to delete possible empty archives from libX11.
I believe that the syntax would be something like this:
# ar -d /usr/X11R6/lib/libX11.a
empty_archive_needs_deleting.o
Most likely, you will have to
run another ranlib command after running ar.
This procedure only works if the desired symbol
is present in a given library,
but the library is not indexed right for some reason.
Later, when you are confident with this procedure,
you can use ar and ranlib
to patch shims into your libraries.
It is very convenient.
- Links
In order to get some programs compiling,
it is convenient to make a few symbolic links.
# ln -s /usr/bin/cc /usr/local/bin/gcc
# ln -s /usr/bin/c++ /usr/local/bin/g++
# ln -s /usr/bin/cc /usr/bin/gcc
# ln -s /usr/bin/c++ /usr/bin/g++
# ln -s /usr/bin/install /usr/bin/install-info
- Finding .h files
Read the locate man page, then use locate
to find .h files that appear to be missing.
Check your -I statements
to be sure the correct include directories are used.
If this doesn't work,
then get your missing .h files from Apple's Darwin CVS
or from the FreeBSD distribution.
- Upgrading your development tools
If you still have problems,
consider upgrading your development tools
(by CVS, from Apple's Darwin page).
O'Reilly has a guide for doing this under OSX:
http://www.oreillynet.com/pub/a/network/2000/12/15/osx_dev.html
- Dummying missing libraries
You can use file links as shown above
to let libraries stand in for missing ones.
Here are some examples:
# ln -s /usr/include/limits.h /usr/local/include/values.h
# touch /usr/include/malloc.h
# echo "dumdum_fun(){}" >the.c
# cc -c the.c
# ar ur /usr/lib/libcompat.a the.o
# ranlib /usr/lib/libcompat.a
I leave it as an exercise to produce similar results
for "-lc", "-lg++", -lpthread",
and so on, if you choose.
- Use switches
For example, the definition of sys_errlist
is a common problem that can be overcome with a switch.
Edit the code around line 265 of /usr/include/stdio.h
so that it looks like this:
#ifdef mygnudarwindef
extern __const char *__const sys_errlist[];
#endif
A similar switch can be installed for the bzero definition,
if that gives you problems.
When you want it to go back to the normal definition,
change the ifdef to ifndef.
Switching is a fine
strategy
for high throughput porting
and bootstrapping the ports tree.
On the other hand, if you are interested
in seeing your favorite programs patched for Darwin,
install Darwin switches in the source code of the port
and send patch files to the package maintainers.
In this way, you will be contributing
to the improvement of free
software,
and the whole
community
will benefit.
- If you still have questions, try posting a message to the one of the
discussion
forums.
http://lists.sourceforge.net/lists/listinfo/gnu-darwin-ports
GNU-Darwin-ports
for discussion of the GNU-Darwin porting engine.
http://lists.sourceforge.net/lists/listinfo/gnu-darwin-distribution
Using
The GNU-Darwin Distribution
Once you get past a certain point,
you will have added enough infrastructure to handle most situations.
Porting will go much faster then.
Thank you for reading these tips.
It is important that we are all on the same page,
and that we keep the project goals in mind as we do the ports.
