]> git.saurik.com Git - apt.git/blame - COMPILING
Latest version from unstable (amd64, etc.)
[apt.git] / COMPILING
CommitLineData
1ae93c94
AL
1General Information
2~~~~~~~~~~~~~~~~~~~
3To compile this you need a couple things
4 - A working POSIX system with working POSIX gcc, g++, make (GNU),
5 ar, sh, awk and sed in the path
6 - GNU Make 3.74 or so, -- normal UNIX make will NOT work
7 * Note 3.77 is broken.
8 - A working ANSI C++ compiler, this is not g++ 2.7.*
9 g++ 2.8 works OK and newer egcs work well also. Nobody has tried it
10 on other compilers :< You will need a properly working STL as well.
11 - A C library with the usual POSIX functions and a BSD socket layer.
678bc33e 12 If you OS conforms to the Single Unix Spec then you are fine:
1ae93c94
AL
13 http://www.opengroup.org/onlinepubs/7908799/index.html
14
678bc33e
AL
15** NOTICE **
16The C++ global constructors do not link correctly when using non-shared
17libaries. This is probably the correct behavior of the linker, but I have
18not yet had time to devise a work around for it. The correct thing to
19do is add a reference to debSystem in apt-pkg/init.cc,
20assert(&debSystem == 0) would be fine for instance.
21
1ae93c94
AL
22Guidelines
23~~~~~~~~~~
24I am not interested in making 'ultra portable code'. I will accept patches
25to make the code that already exists conform more to SUS or POSIX, but
26I don't really care if your not-SUS OS doesn't work. It is simply too
27much work to maintain patches for dysfunctional OSs. I highly suggest you
28contact your vendor and express intrest in a conforming C library.
29
30That said, there are lots of finniky problems that must be delt with even
31between the supported OS's. Primarily the path I choose to take is to put
32a shim header file in build/include that transparently adds the required
33functionality. Patches to make autoconf detect these cases and generate the
34required shims are OK.
35
36Current shims:
678bc33e
AL
37 * C99 integer types 'inttypes.h'
38 * sys/statvfs.h to convert from BSD/old-glibc statfs to SUS statvfs
1ae93c94 39 * rfc2553 hostname resolution (methods/rfc*), shims to normal gethostbyname.
1cecba4d
AL
40 The more adventerous could steal the KAME IPv6 enabled resolvers for those
41 OS's with IPv6 support but no rfc2553 (why?)
678bc33e 42 * define _XOPEN_EXTENDED_SOURCE to bring in h_errno on HP-UX
1cecba4d 43 * socklen_t shim in netdb.h if the OS does not have socklen_t
1ae93c94 44
a5bae0df 45The only completely non-shimed OS is Linux with glibc2.1, glibc2.0 requires
1cecba4d 46the first three shims.
1ae93c94
AL
47
48Platform Notes
49~~~~~~~~~~~~~~
50Debian GNU Linux 2.1 'slink'
51Debian GNU Linux 'potato'
678bc33e 52Debian GNU Linux 'woody'
1ae93c94
AL
53 * All Archs
54 - Works flawlessly
678bc33e 55 - You will want to have debiandoc-sgml and docbook2man installed to get
1ae93c94 56 best results.
1cecba4d 57 - No IPv6 Support in glibc's < 2.1.
1ae93c94
AL
58
59Sun Solaris
60 SunOS cab101 5.7 Generic_106541-04 sun4u sparc
678bc33e 61 SunOS csu201 5.8 Generic_108528-04 sun4u sparc
1ae93c94
AL
62 - Works fine
63 - Note, no IPv6 Support, OS lacks RFC 2553 hostname resolution
a5bae0df
AL
64
65OpenBSD
66 OpenBSD gsb086 2.5 CMPUT#0 i386 unknown
678bc33e 67 OpenBSD csu101 2.7 CMPUT#1 i386 unknown
1cecba4d
AL
68 - OS needs 'ranlib' to generate the symbol table after 'ar'.. (not using
69 GNU ar with the gnu tool chain :<)
678bc33e
AL
70 - '2.5' does not have RFC 2553 hostname resolution, but '2.7' does
71 - Testing on '2.7' suggests the OS has a bug in its handling of
72 ftruncate on files that have been written via mmap. It fills the page
73 that crosses the truncation boundary with 0's.
74
1ae93c94
AL
75HP-UX
76 HP-UX nyquist B.10.20 C 9000/780 2016574337 32-user license
77 - Evil OS, does not conform very well to SUS
78 1) snprintf exists but is not prototyped, ignore spurios warnings
79 2) No socklen_t
80 3) Requires -D_XOPEN_SOURCE_EXTENDED for h_errno
1cecba4d 81 configure should fix the last two (see above)
1ae93c94
AL
82 - Note, no IPv6 Support, OS lacks RFC 2553 hostname resolution
83