Re: web/xml/porting porting.en.xml,1.5,1.6
"Daniel E. Macks" <[email protected]> Wed, 16 Mar 2005 19:03:41 +0000 (UTC)
| Newsgroups | gmane.os.apple.fink.i18n |
|---|---|
| Message-ID | <[email protected]> |
Daniel Macks <[email protected]> said: > > Modified Files: > porting.en.xml > Log Message: > Adding 10.3 material. This ia a whole new section (and some small scattered changes). > RCS file: /cvsroot/fink/web/xml/porting/porting.en.xml,v > --- porting.en.xml 16 Mar 2005 18:33:31 -0000 1.5 > +++ porting.en.xml 16 Mar 2005 18:49:05 -0000 1.6 > @@ -40,7 +40,7 @@ > > <p>Short story: If configure fails with 'Can't determine host type', copy config.guess and config.sub from /usr/share/libtool (/usr/libexec for OS versions prior to 10.2) into the current directory.</p> > > - <p>Long story: The GNU world uses a canonical format to specify system types. It has three parts: cpu type, manufacturer and operating system. Sometimes a fourth part is added - then the third part denotes the kernel, while the fourth denotes the operating system. All parts are lower case and concatenated using dashes. Some examples: <code>i586-pc-linux-gnu</code>, <code>hppa1.1-hp-hpux10.20</code>, <code>sparc-sun-solaris2.6</code>. The host type for Mac OS X 10.0 is <code>powerpc-apple-darwin1.3</code>. Versions of Mac OS X 10.2 bring various <code>powerpc-apple-darwin6.x.0</code>, where "x" depends on the exact OS revision.</p> > + <p>Long story: The GNU world uses a canonical format to specify system types. It has three parts: cpu type, manufacturer and operating system. Sometimes a fourth part is added - then the third part denotes the kernel, while the fourth denotes the operating system. All parts are lower case and concatenated using dashes. Some examples: <code>i586-pc-linux-gnu</code>, <code>hppa1.1-hp-hpux10.20</code>, <code>sparc-sun-solaris2.6</code>. The host type for Mac OS X 10.0 is <code>powerpc-apple-darwin1.3</code>. Versions of Mac OS X 10.2 bring various <code>powerpc-apple-darwin6.x.0</code> and 10.3 gives <code>powerpc-apple-darwin7.x.0</code>, where "x" depends on the exact OS version.</p> > > <p>Many packages that use autoconf want to know the host type of the system they are compiled on. (Side note: to support cross-compiling and porting, there are actually three types - the host type, the build type and the target type. Usually, they're all the same.) You can either pass the host type to the configure script as a parameter or you can let it guess.</p> > > @@ -231,6 +231,8 @@ > Side note: > The libltdl library included with all libtool versions will only work > on Darwin when dlcompat is installed. > +This is included with OS X starting with 10.3. For previous versions, > +one can install the fink "dlcompat" family of packages. > </p> > </section> > > @@ -496,8 +498,125 @@ > <chapter filename="preparing-10.3"> > <title>Preparing for 10.3</title> > <shorttitle>Preparing for 10.3</shorttitle> > + > <section name="perl"><title>Perl</title> > + > + <p> > + In OS X 10.2, <filename>/usr/bin/perl</filename> was perl 5.6.0 > + and the architecture string was "darwin". In OS X > + 10.3, <filename>/usr/bin/perl</filename> was upgraded to perl > + 5.8.1 and the architecture string was changed to > + "darwin-thread-multi-2level". These changes <em>probably</em> do > + not affect ordinary uses of the perl executable for package > + creation since each perl executable knows where to find its own modules. > + Maintainers of perl-module ("-pm") packages who follow the current > + <link > + url="http://fink.sourceforge.net/packaging/policy.php#perlmods">Perl > + Modules packaging policy</link> and are careful to follow the > + <code>CompileScript</code> and <code>InstallScript</code> > + documentation will already have things set up correctly. > + </p> > + > </section> > + > +<section name="typedef"><title>New symbol definitions</title> > + > + <p> > + Starting in Mac OS X 10.3, there is now always a complete > + definition for the <code>socklen_t</code> type. To get this > + typedef defined, you may need to add to your program: > + </p> > + <codeblock> > +#include <sys/types.h> > +#include <sys/socket.h> > + </codeblock> > + > +</section> > + > +<section name="system-libs"><title>New builtin system libraries</title> > + > + <p> > + Mac OS X 10.3 includes several libraries that were not in previous > + system releases, and so were provided as fink packages: > + </p> > + > + <itemtable> > + <item> > + <itemt>libpoll</itemt> > + <itemd> > + <p> > + The files <filename>/usr/lib/libpoll.dylib</filename> and > + <filename>/usr/include/poll.h</filename> are now included, > + however the OS X-supplied implementation of this library is > + not complete. If it is sufficient for your purposes, you can > + remove dependencies on the Fink "libpoll" and > + "libpoll-shlibs" packages. The library code is > + actually incorporated into libSystem, which is automatically > + linked. That means that <code>-lpoll</code> is not necessary > + if you wish to use the OS X implementation. Be aware that OS > + X supplies a <filename>libpoll.dylib</filename>, so > + <code>-lpoll</code> may give different results depending on > + whether you have the Fink "libpoll" package > + installed or not. > + </p> > + </itemd> > + </item> > + <item> > + <itemt>libdl</itemt> > + <itemd> > + <p> > + The files <filename>/usr/lib/libdl.dylib</filename> > + and <filename>/usr/include/dlfcn.h</filename> are now included, so you should > + not need dependencies on the Fink "dlcompat", > + "dlcompat-dev", and "dlcompat-shlibs" packages. The library > + code is actually incorportated into libSystem, which is > + automatically linked. That means that <code>-ldl</code> is > + not necessary (but has no effect if used). > + </p> > + </itemd> > + </item> > + <item> > + <itemt>GNU getopt</itemt> > + <itemd> > + <p> > + This library, including the <code>getopt_long()</code> > + function, has been incorportated into libSystem and > + <filename>/usr/include/getopt.h</filename>, so you may not > + need to use the Fink "libgnugetopt" and > + "libgnugetopt-shlibs" packages. Because libSystem is > + automatically linked and <filename>/usr/include</filename> > + is automatically searched for headers, you could remove any > + <code>-lgnugetopt</code> > + and <code>-I/sw/include/gnugetopt</code> flags that were > + manually added in order to access Fink's > + "libgnugetopt". > + </p> > + </itemd> > + </item> > + </itemtable> > + > + <p> > + When migrating a package to OS X 10.3, try to remove these > + deprecated dependencies, as those packages may be removed from these > + newer package trees in the future. This means you will need a separate > + package description file for each tree. As always, > + the <code>Revision</code> must be increased when making changes to > + a package. In this manner, a user who upgrades from OS X 10.2 to > + 10.3 will see 10.3-specific packages as "newer" than his > + existing 10.2 ones. By convention, the <code>Revision</code> > + should be increased by 10 when changes are made for migration to a > + higher tree inn order to leave space for the lower-tree package to be > + updated in the future. > + </p> > + > + <p> > + When testing a migrated package, make sure to uninstall the > + packages whose <code>BuildDepends</code> you removed. Otherwise > + the compiler may still link the Fink-supplied libraries. > + </p> > + > +</section> > + > </chapter> > > </document> -- Daniel Macks [email protected] http://www.netspace.org/~dmacks ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click