This is some early thoughts on the process of building LIBC and the other tools in the LIBC repository. People with better english skills and first hand experience in doing this stuff from scratch are welcome to help filling in the gaps.
Select Source Tree
Before even checking out the sources, you have to decide which sources to get. There are the following options:
- The trunk - development branch. url: http://svn.netlabs.org/repos/libc/trunk/
Choose this if you are interested in helping out with/on new features and make the new world a better place.
- The libc-0.6 branch - release branch. url: http://svn.netlabs.org/repos/libc/branches/libc-0.6/
Choose this if you are out for bugfixing in or backporting bugfixes to in this release, of if you are simply hunrgy from something to build.
This is also the right choice if you want something which is 100% sure to be usable.
- The libc-0.5 branch - old release branch. url: http://svn.netlabs.org/repos/libc/branches/GCC_3-2-2_BETA4_BRANCH/
Choose this if you have critical bugs which needs fixing in the 0.5 release. Only critical fixes are accepted.
Checking Out The Tree
First you need a copy of subversion for OS/2 available here http://silk.apana.org.au/subversion/ Installation is as simple as copying the binaries to your PATH and having a HOME directory set. Create a folder, perhaps Innotek_libc, cd into it and enter svn co URL so to pull the trunk the command would be
which will create a directory called trunk and mirror the Netlabs trunk repositry. For other interesting targets see Select Source Tree.
If you check out the thunk you will need kBuild. kBuild is not converted to svn yet, so you'll have to dig up a working cvs client. What to do:
- Go to the root dir in the trunk checkout.
- cvs -d :pserver:firstname.lastname@example.org:/netlabs.cvs/kbuild login (password: readonly)
- cvs -d :pserver:email@example.com:/netlabs.cvs/kbuild co kBuild
- Now you should have a subdirectory called kBuild in the root of the trunk checkout.
Setting Up The Build Environment
This is gonna be difficult to explain. esp. since I'm using a clash together mixup here...
- Latest GCC release. Check ftp://ftp.netlabs.org/pub/gcc/
N.B. For building the 0.5 branch you should probably use the latest 3.2.2 release from http://www.innotek.de/products/gccos2/download/gccos2download_e.html
- Latest GNU Make 3.81 beta available at http://www.unixos2.org/sw/pub/binary/make/make-3.81beta3-r2-bin.zip. TODO: Build this with libc-0.6 and find somewhere to put the build.
In the trunk there is a environment setup script called env.cmd (on unix it will be called env.sh). You should run this to setup the proper environment for building libc.
Note: The current state of the trunk isn't buildable and the env.cmd script is but a draft which only works on my PC.
Doing The Build
The instructions differents between the trunk and the branches. The repository is begin reorganized after the libc-0.6 release branch was created and is currently in the process of being switched over to a different build system (at least the non gnu bits).
Building The Trunk
You have two choices, build everything or just a single component. When building single components you go into the root directory for that component. For libc that means /libc.
libc and emx are currently in an intermediate shape buildsystem wise, and you'll have to specify the makefile on the make commandline: make -f Makefile.gmk This will print a menu of the make goals. The all and install goals are choices you can't go wrong with.
Building gcc and binutils means using the GNU buildsystem. Explain about the GNU buildsystem, blah blah blah.
It is not permitted for anyone other than the release engineer (i.e. bird) to publish libc builds using the natural series of dll names, since this will cause confusion among users and incompatibility between the official releases and your releases. Not complying with this simple rule is a sure way of pissing people of, at least bird.
The natural series is expressed by this regexp '/libc[0-9][0-9][0-9]*[abr]*[0-9]*\.dll$/'. Examples: libc05.dll, libc06.dll, libc06a1.dll, libc06b4.dll, libc06r2.dll, libc07r1.dll, libc10.dll, and libc100a.dll
Documenting your build is vital. It should be made exceptionally clear that the build is not an official one, that you did it, what is special about your build, what it includes which is different from the official ones, and how to reconstruct the sources (diff + what you diffed against or/and subversion tree revision(s)). It is also worth keeping in mind that LIBC is LGPL and most of the other stuff is GPL (the exceptions are ash,.. which are BSD). So, don't forget to include COPYING.LIB and/or COPYING when appropriate.