由 configure 所產生的檔案

3.2 Files generated by configure / 由 configure 所產生的檔案

After you have invoked `configure', you will discover a number of generated files in your build tree. The build directory structure created by `configure' and the number of files will vary from package to package. Each of the generated files are described below and their relationships are shown in C. Generated File Dependencies:

在執行 `configure' 之後，你會發現有一些檔案在你的建置資料夾中被產生出來。在不同的套件中，由 `configure' 在建置資料夾所建立的資料夾結構以及檔案的數量會稍有不同。以下簡述所產生的檔案的功能，這些檔案間的關係則在 C. 所產出檔案間的相依性中描述:

`config.cache'

`configure' can cache the results of system tests that have been performed to speed up subsequent tests. This file contains the cache data and is a plain text file that can be hand-modified or removed if desired.

`configure' 可以藉由儲存系統測試程式的結果，來縮短後續測試所耗的時間。所儲存的快取資訊會以純文字的形式存放在這個檔案中，如果有需要的話，可以手動編修或移除這個檔案。

`config.log'

As `configure' runs, it outputs a message describing each test it performs and the result of each test. There is substantially more output produced by the shell and utilities that `configure' invokes, but it is hidden from the user to keep the output understandable. The output is instead redirected to `config.log'. This file is the first place to look when `configure' goes hay-wire or a test produces a nonsense result. A common scenario is that `configure', when run on a Solaris system, will tell you that it was unable to find a working C compiler. An examination of `config.log' will show that Solaris' default `/usr/ucb/cc' is a program that informs the user that the optional C compiler is not installed.

在 `configure' 執行時，會印出一些訊息來描述正在執行的測試，以及測試的結果。實際上，由 shell 以及 `configure' 所執行的工具程式會送出更多的訊息，但是為了讓印到輸出畫面的資訊較容易被使用者理解，這些額外的訊息不會被送到輸出畫面上。所有額外的訊息會被導向到 `config.log' 檔案中，當 `configure' 程式作出怪異的行為或是產生莫名奇妙的測試結果時，這個檔案是第一個該看看的地方。一個常見的例子是，在 Solaris 系統上執行 `configure' 時顯示找不到可以使用的編譯器的訊息。在檢視 `config.log' 後就會發現，在 Solaris 上所預先安裝的 `/usr/ucb/cc' 是一個顯示 C 編譯器尚未安裝的程式，並非是一個可用的編譯器。

`config.status'

`configure' generates a shell script called `config.status' that may be used to recreate the current configuration. That is, all generated files will be regenerated. This script can also be used to re-run `configure' if the `--recheck' option is given.

`configure' 會產生一個稱為 `config.status' 的 shell 指令稿，這個指令稿可以用來重新建立目前的組態環境。換言之，這個指令稿會重新產生所有 `configure' 所產生的檔案。另外，只要在執行時給定 `--recheck' 的選項，也可以透過這個指令稿來重新執行 `configure' 程式。

`config.h'

Many packages that use `configure' are written in C or C++. Some of the tests that `configure' runs involve examining variability in the C and C++ programming languages and implementations thereof. So that source code can programmatically deal with these differences, #define preprocessor directives can be optionally placed in a config header, usually called `config.h', as `configure' runs. Source files may then include the `config.h' file and act accordingly:

許多使用 `configure' 的套件是由 C 或 C++ 所撰寫的，有許多 `configure' 所執行的測試正是用來檢驗執行建置程序的 C/C++ 編譯器所提供的語言實作細節，以及檢驗諸如函式庫的版本或存在與否等編譯環境所提供支援的程度。測試所得的結果可以由 #define 前置處理指引的方式表現出來，通常會存放到檔名為 `config.h ' 的設定標頭檔中。在程式的原始碼中就可以引入 `config.h' 並且針對各個狀況來撰寫特定的程式碼片段分別處理，比如:

#if HAVE_CONFIG_H # include #endif /* HAVE_CONFIG_H */ #if HAVE_UNISTD_H # include #endif /* HAVE_UNISTD_H */

We recommend always using a config header.

我們建議所有的專案都應該使用設定標頭檔。

`Makefile'

One of the common functions of `configure' is to generate `Makefile's and other files. As it has been stressed, a `Makefile' is just a file often generated by `configure' from a corresponding input file (usually called `Makefile.in'). The following section will describe how you can use make to process this `Makefile'. There are other cases where generating files in this way can be helpful. For instance, a Java developer might wish to make use of a `defs.java' file generated from `defs.java.in'.

其中一個 `configure' 常被用到的功能是產生 `Makefile' 檔，或是其他有用的檔案。正如同之前所提到的，一個 `Makefile' 檔通常會是一個由 `configure' 分析一個對應的輸入檔 (通常會是 `Makefile.in') 所產生，接下來的章節會描述如何執行 make 來使用 `Makefile' 檔案。類似的方法也可以用在其他場合來產生有用的檔案，比如，一個 Java 程式設計師可能會想從一個 `defs.java.in' 來產生出 `defs.java' 檔。

進行組態

3.1 Configuring / 進行組態

A `configure' script takes a large number of command line options. The set of options can vary from one package to the next, although a number of basic options are always present. The available options can be discovered by running `configure' with the `--help' option. Although many of these options are esoteric, it's worthwhile knowing of their existence when configuring packages with special installation requirements. Each option will be briefly described below:

`configure' 指令稿接受一大堆的命令列選項，不同的套件所能夠接受的選項會不太一樣，有一些基本的選項在所有套件中都可以找到，各套件所可以接受的選項可以透過執行 `configure' 時加上 `--help' 選項取得。雖然有不少的選項通常不會被用到，但有特殊的需求時，知道一下這些選項的存在會很有幫助。以下簡述在所有套件中都能找到的基本選項:

`--cache-file=file'

`configure' runs tests on your system to determine the availability of features (or bugs!). The results of these tests can be stored in a cache file to speed up subsequent invocations of configure. The presence of a well primed cache file makes a big improvement when configuring a complex tree which has `configure' scripts in each subtree.

`configure' 會在你的系統執行測試程式以檢查系統所能提供的功能 (或是系統的錯誤與漏洞)，測試的結果會被存在一個快取檔案中，以縮短未來執行 configure 所耗用的時間。一些複雜的專案的原始碼樹在每個子資掉夾都有各自的 `configure' 指令稿，在這個情況下，可以透過留置快取檔案來大幅縮減組態所耗用的時間。

`--help'

Outputs a help message. Even experienced users of `configure' need to use `--help' occasionally, as complex projects will include additional options for per-project configuration. For example, `configure' in the GCC package allows you to control whether the GNU assembler will be built and used by GCC in preference to a vendor's assembler.

輸出說明訊息，因為一些複雜的專案會在 `configure' 中加入一些額外的選項，因此即使是有經驗的使用者偶而也需要使用 `--help' 選項。比如，在 GCC 套件的 `configure' 中就可以讓你控制是不是要建置 GNU 組譯器並讓 GCC 使用，或是要使用其他廠商所提供的組譯器。

`--no-create'

One of the primary functions of `configure' is to generate output files. This option prevents `configure' from generating such output files. You can think of this as a kind of dry run, although the cache will still be modified.

`configure' 的主要功能之一是產生用來建置套件的檔案，給定這個選項會讓 `configure' 不產生那些檔案，但快取檔仍會被修改，你可以將這個功能視為進行測試用的功能。

`--quiet'
`--silent'

As `configure' runs its tests, it outputs brief messages telling the user what the script is doing. This was done because `configure' can be slow. If there was no such output, the user would be left wondering what is happening. By using this option, you too can be left wondering!

在 `configure' 進行測試時，他會輸出一些簡單的訊息告訴使用者指令稿正在做什麼。因為 `configure' 的執行會花很多時間，如果沒有輸出這些東西，使用者只能在旁邊瞎猜現在的狀況。只要給定了這個選項，你就可以重新加入大家來瞎猜的行列。

`--version'

Prints the version of Autoconf that was used to generate the `configure' script.

印出產生這個 `configure' 指令稿的 Autoconf 版本。

`--prefix=prefix'

The --prefix option is one of the most frequently used. If generated `Makefile's choose to observe the argument you pass with this option, it is possible to entirely relocate the architecture-independent portion of a package when it is installed. For example, when installing a package like Emacs, the following command line will cause the Emacs Lisp files to be installed in `/opt/gnu/share':

--prefix 是經常被使用的一個選項，如果所產生的 `Makefile' 會嚴格遵守你隨著這個選項所傳入的參數，那麼就可以把整個套件中與硬體平台無關的部分安裝到預設路徑外的地方去。比如說，利用以下的指令安裝 Emacs 套件，會讓 Emacs 的 Lisp 檔案安裝到 `/opt/gnu/share' 之下:

$ ./configure --prefix=/opt/gnu

It is important to stress that this behavior is dependent on the generated files making use of this information. For developers writing these files, Automake simplifies this process a great deal. Automake is introduced in 7. Introducing GNU Automake.

很重要的一點是，所產生的檔案必須要會使用這項資訊。對於撰寫設定檔的開發者，使用 Automake 可以大幅簡化這個步驟，我們會在 7. GNU Automake 簡介中介紹 Automake。

`--exec-prefix=eprefix'

Similar to `--prefix', except that it sets the location of installed files which are architecture-dependent. The compiled `emacs' binary is such a file. If this option is not given, the default `exec-prefix' value inserted into generated files is set to the same value as the `prefix'.

這個選項與 `--prefix' 類似，但所指定的路徑位址是給與硬體平台相關的檔案使用的，比如所編譯出來的 `emacs' 執行檔。如果這個選項沒有給定，預設的 `exec-prefix' 值會被設定為 `prefix' 的值。

`--bindir=dir'

Specifies the location of installed binary files. While there may be other generated files which are binary in nature, binary files here are defined to be programs that are run directly by users.

給定要安裝執行檔的路徑位置，套件建置可能會產生很多各式各樣的執行檔，但這個選項所指的執行檔僅包含會被使用者直接執行的程式。

`--sbindir=dir'

Specifies the location of installed superuser binary files. These are programs which are usually only run by the superuser.

給定要安裝管理員用執行檔的路徑位置，這些程式通常只由系統管理員使用。

`--libexecdir=dir'

Specifies the location of installed executable support files. Contrasted with `binary files', these files are never run directly by users, but may be executed by the binary files mentioned above.

給定要安裝可執行的支援檔案的路徑位置，與上面所提及的 `執行檔' 所不同，被這個選項所指的檔案不會被使用者直接的執行，但可能會被上面所說的執行檔所執行。

`--datadir=dir'

Specifies the location of generic data files.

給定要安裝一般性的資料檔的路徑位置。

`--sysconfdir=dir'

Specifies the location of read-only data used on a single machine.

給定在單一機器上的設定資料的路徑位置，這些設定資料對一般使用者是唯讀的，且一般而言不同的機器會有不同的設定。

`--sharedstatedir=dir'

Specifies the location of data which may be modified, and which may be shared across several machines.

給定共用可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，並且可能會在數臺不同的機器所共享。

`--localstatedir=dir'

Specifies the location of data which may be modified, but which is specific to a single machine.

給定專屬可讀寫資料的路徑位置，這些資料檔可以被使用者所更改，但只會由一臺機器存取使用。

`--libdir=dir'

Specifies where object code library should be installed.

給定安裝函式庫目的碼的路徑位置。

`--includedir=dir'

Specifies where C header files should be installed. Header files for other languages such as C++ may be installed here also.

給定安裝 C 標頭檔案的路徑位置，如 C++ 等其他語言所使用的標頭檔也可能會被安裝在這個選項所指定的路徑下。

`--oldincludedir=dir'

Specifies where C header files should be installed for compilers other than GCC.

給定安裝給非 GCC 的其他編譯器所使用的 C 標頭檔案的路徑位置。

`--infodir=dir'

Specifies where Info format documentation files should be installed. Info is the documentation format used by the GNU project.

給定安裝 Info 格式文件檔的路徑位置，Info 是被 GNU 計畫所使用的文件檔案格式。

`--mandir=dir'

Specifies where manual pages should be installed.

給定安裝使用手冊的路徑位置。

`--srcdir=dir'

This option does not affect installation. Instead, it tells `configure' where the source files may be found. It is normally not necessary to specify this, since the configure script is normally in the same directory as the source files.

這個選項不會影響到安裝，但可以裡用這個選項告訴 `configure' 套件原始碼所在位置。通常並不需要設定這個選項，因為 configure 指令稿通常會與原始碼放在一樣的資料夾內。

`--program-prefix=prefix'

Specifies a prefix which should be added to the name of a program when installing it. For example, using `--program-prefix=g' when configuring a program normally named `tar' will cause the installed program to be named `gtar' instead. As with the other installation options, this `configure' option only works if it is utilized by the `Makefile.in' file.

給定要在安裝個別執行檔時接到預設程式檔名之前的前置字串，比如，在組態 tar 套件時使用 `--program-prefix=g' 會讓正常情況下稱為 `tar' 的程式被更名為 `gtar'。就像其他的安裝選項，這個 `configure' 選項只在 `Makefile.in' 有使用到這個設定時才有效。

`--program-suffix=suffix'

Specifies a suffix which should be appended to the name of a program when installing it.

給定要在安裝個別執行檔時接到預設程式檔名之後的後置字串。

`--program-transform-name=program'

Here, program is a sed script. When a program is installed, its name will be run through `sed -e script' to produce the installed name.

在這裡的 program 是一個 sed 指令稿，在安裝個別執行檔時，預設的執行檔名會送進 `sed -e script' 以產生各執行檔的檔名。

`--build=build'

Specifies the type of system on which the package will be built. If not specified, the default will be the same configuration name as the host.

給定執行套件建置的系統平台名稱，如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--host=host'

Specifies the type of system on which the package will run--or be hosted. If not specified, the host triplet is determined by executing `config.guess'.

給定將執行或安裝套件程式的系統平台名稱，如果這個選項沒有給定，預設將會執行 `config.guess' 來取得系統平台名稱。

`--target=target'

Specifies the type of system which the package is to be targeted to. This makes the most sense in the context of programming language tools like compilers and assemblers. If not specified, the default will be the same configuration name as the host.

給定套件的目標系統平台，這個選項在建置如編譯器或組譯器等程式語言工具時會較有意義。如果這個選項沒有給定，預設將會使用與 host 相同的值。

`--disable-feature'

Some packages may choose to provide compile-time configurability for large-scale options such as using the Kerberos authentication system or an experimental compiler optimization pass. If the default is to provide such features, they may be disabled with `--disable-feature', where feature is the feature's designated name. For example:

有些套件會讓使用者在編譯時期決定是不是要將像 Kerberos 認証系統之類較龐大的額外功能，或是實驗性的編譯時期最佳化選項納入建置。如果這些額外的功能預設是開啟的，那麼可以利用 `--disable-feature' 來將他們關閉，在這邊 feature 應代換為功能的代稱，例如:

$ ./configure --disable-gui

`--enable-feature[=arg]'

Conversely, some packages may provide features which are disabled by default. To enable them, use `--enable-feature', where feature is the feature's designated name. A feature may accept an optional argument. For example:

相反的，有些套件會將額外的功能預設為關閉。使用 `--enable-feature' 可以啟用這些額外的功能，在這邊 feature 應代換為功能的代稱。有些功能可以接受額外的參數，例如:

$ ./configure --enable-buffers=128

Using `--enable-feature=no' is synonymous with `--disable-feature', described above.

使用 `--enable-feature=no' 跟使用上面提到的 `--disable-feature' 會有相同的效果。

`--with-package[=arg]'

In the free software community, there is a healthy tendency to reuse existing packages and libraries where possible. At the time when a source tree is configured by `configure', it is possible to provide hints about other installed packages. For example, the BLT widget toolkit relies on Tcl and Tk. To configure BLT, it may be necessary to give `configure' some hints about where you have installed Tcl and Tk:

儘可能利用既有的套件與函式庫是自由軟體社群中一項健康的潮流，當利用 `configure' 對原始碼樹進行組態時，這個選項可以用來提供一些系統既有套件的資訊。例如 BLT widget toolkit 需要 Tcl 與 Tk 事先安裝在系統上，在組態時可能需要給 `configure' 一些關於 Tcl 與 Tk 安裝位置的提示:

$ ./configure --with-tcl=/usr/local --with-tk=/usr/local

Using `--with-package=no' is synonymous with `--without-package' which is described below.

使用 `--with-package=no' 與使用將在下面提到的 `--without-package' 會有相同的效果。

`--without-package'

Sometimes you may not want your package to inter-operate with some pre-existing package installed on your system. For example, you might not want your new compiler to use GNU ld. You can prevent this by using an option such as:

有時候你可能會不希望你建置的套件程式去使用系統內已安裝的套件，比如說，你可能不想讓新的編譯器使用 GNU ld 來連結程式。你可以用像下面這樣的選項來達到這個目的:

$ ./configure --without-gnu-ld

`--x-includes=dir'

This option is really a specific instance of a `--with-package' option. At the time when Autoconf was initially being developed, it was common to use `configure' to build programs to run on the X Window System as an alternative to Imake. The `--x-includes' option provides a way to guide the configure script to the directory containing the X11 header files.

這個選項其實是 `--with-package' 的一個特例。在 Autoconf 的開發初期, `configure' 常被用來作為 Imake 外的另一個建置 X Window System 應用程式的選擇。透過 `--x-includes' 選項，使用者可以告知 configure 指令稿 X11 的標頭檔所在的資料夾。

`--x-libraries=dir'

Similarly, the --x-libraries option provides a way to guide `configure' to the directory containing the X11 libraries.

與前項相似，透過 `--x-libraries' 選項，使用者可以告知 configure 指令稿 X11 函式庫檔所在的資料夾。

It is unnecessary, and often undesirable, to run `configure' from within the source tree. Instead, a well-written `Makefile' generated by `configure' will be able to build packages whose source files reside in another tree. The advantages of building derived files in a separate tree to the source code are fairly obvious: the derived files, such as object files, would clutter the source tree. This would also make it impossible to build those same object files on a different system or with a different configuration. Instead, it is recommended to use three trees: a source tree, a build tree and an install tree. Here is a closing example of how to build the GNU malloc package in this way:

在原始碼樹中執行 `configure' 是不必要也不被建議的，到原始碼樹之外的資料夾中執行 `configure' 來產生 `Makefile' 檔案並建置套件會比較好。在與原始碼樹分離的資料夾建置套件的優點是顯而易見的: 諸如目的檔等由建置程序所產生的檔案，將不會混雜到原始碼樹之中。此外，也可以在與原始碼樹分離的數個資料夾中分別進行建置動作，如此一來能讓一套原始碼可同時用來建置出給不同系統使用的執行檔，或是針對不同的組態分別進行建置作業。因此，我們建議的做法是在每次的建置作業中使用到三個不同的資料夾: 原始碼樹、建置資料夾以及安裝資料夾。以下是一個使用這個方法來建置 GNU malloc 套件的例子:

$ gtar zxf mmalloc-1.0.tar.gz $ mkdir build && cd build $ ../mmalloc-1.0/configure creating cache ./config.cache checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for a BSD compatible install... /usr/bin/install -c checking host system type... i586-pc-linux-gnu checking build system type... i586-pc-linux-gnu checking for ar... ar checking for ranlib... ranlib checking how to run the C preprocessor... gcc -E checking for unistd.h... yes checking for getpagesize... yes checking for working mmap... yes checking for limits.h... yes checking for stddef.h... yes updating cache ../config.cache creating ./config.status

Now that this build tree is configured, it is possible to go on and build the package and install it into the default location of `/usr/local':

現在，建置資料夾已經組態完成，接下來就可以使用以下指令來進行建置作業，並將成品安裝到預設的安裝資料夾 `/usr/local' 中:

$ make all && make install

關閉 Windows 檔案總管的影像檔案預覽功能

檔案預覽功能，主要就是滑鼠點在檔案上的時候，檔案總管會顯示影片或是圖片檔的縮圖在旁邊，底下的狀態列也會顯示諸如維度、彩色編碼模式、檔案註解等等資訊。

個人覺得是沒啥用的一個功能，而且電腦慢一點的話，在產生這些資訊的同時，諸如更名或是刪除等檔案操作都會因為檔案總管正在對檔案讀取以製作預覽而無法使用，得等個半天才能做檔案操作。

關閉圖片與影片的預覽可以使用下面這兩個指令:

regsvr32 /u shimgvw.dll
regsvr32 /u shmedia.dll

第一個指令會關閉圖片預覽，第二個指令則是關閉影片預覽。

要重新開啟圖片與影片的預覽則可以使用下面這兩個指令:

regsvr32 shimgvw.dll
regsvr32 shmedia.dll

同樣分別是針對圖片與影片發生作用，可以視情況擇一使用。

抽換掉 Fedora 9 網路安裝影像檔的核心

預設的影像檔內附的核心的網路驅動程式似乎是有問題，安裝到一半會發生 IRQ 處理異常，然後會整個停在那邊。

解決之道就是把核心換掉，不過換掉核心連帶的也得換掉驅動程式，所以不能單純的把 zImage 檔中核心的部分抽換，也要改 initrd 影像，用下面這個指令可以把 initrd 影像解出來。

objcopy -j .kernel:initrd -O binary zImage initrd.gz

接這就可以用 gzip 把影像檔解開得到 cpio 檔案，接著用下面這個指令解開 cpio 檔案。

cpio -idv < INPUT-FILE.cpio

把原本的 initrd 解開之後，找 anaconda 的 scripts/mk-images 來加以修改。重點在於執行 makemoduletree() 這個函式，可以參考 scripts/mk-images.ppc 來驅動 makeinitrd() 去執行 makemoduletree() 來產出 kernel object 的資料夾。

主要是把 /modules 的檔案都替換掉就沒有大問題了，接著在相當於 / 的檔案系統根目錄執行下面這個指令，來把檔案系統打包成 gzip 壓縮的 cpio 檔案。

find . | cpio --quiet -c -o | gzip --best > OUTPUT-FILE.initrd

給 Open Firmware 的 BOOTP 用的 zImage 檔基本上是 ELF32-BE 的格式的檔案，在 Fedora 7 的時候 kernel 會去找 .data 節區來作為 initrd 影像來源，不過在 Fedora 9 則是找 .kernel:initrd 這個節區。如果在 Fedora 7 上用 mkzimage 去做的話，開機的時候會當掉。

所以舊的給 Fedora 7 的 mkzimage 指令就不能用了，要找新的位於 kernel-bootwrapper 套件內的 wrapper 指令來用，單純解開來用的話要改一下 wrapper 裡的 $object 與 $objbin 這兩個變數，把他的內容指到解開套件的位置。

這部分我是這樣子改:

rootpath=%TEMP_WORKSPACE%
object=$rootpath/usr/lib64/kernel-wrapper
objbin=$rootpath/usr/sbin

OpenOffice.org 3.0 for MacOS

上次試用好像是 alpha 版本的時代吧！之前是使用 Neo Office 不過總是感覺有點頓，而且 2.2 的功能與界面有點粗，所以還是比較期待 3.0 的 Aqua native build 版本。

因為我的機器是 PowerPC 處理器，所以目前可以拿到的 pre-build binary 只有 RC4 版，據說幾乎就是 release 版了。

還是有點頓頓的，啟動仍是頗慢，檔案也是相當大！這個東西跟 Java 一樣都變成怪物了吧！比較好的是，比起 alpha 版超級無敵漫長的啟動時間並且動一下就當掉，現在的狀況已經改善很多。

nmap 是好物

今天要連某微型叢集內的某臺機器，不過因為整個不是我組態的，所以哪臺機器 IP 是多少我不太記得。

以前是自己臨場刻個 perl script 來掃，今天想一想還是找找看有啥工具。果然有個好物

nmap -sP 192.168.10.0/24

速度當然是比自己刻的快太多了，一下子就找到我要找的機器。

如何執行 configure 與 make

3. How to run configure and make / 如何執行 configure 與 make

A package constructed using Autoconf will come with a `configure' script. A user who wants to build and install the package must run this script in order to prepare their source tree in order to build it on their particular system. The actual build process is performed using the make program.

一個使用 Autoconf 建構的套件會含有一個 `configure' 指令稿，想要建置與安裝套件的使用者必須先執行這個指令稿，以針對使用者的系統調整所取得的原始碼樹。實際的建置程序，則是利用 make 程式來執行。

The `configure' script tests system features. For example, it might test whether the C library defines the time_t data type for use by the time() C library function. The `configure' script then makes the results of those tests available to the program while it is being built.

`configure' 指令稿會測試系統所支援的功能，舉例來說，他可能會測試 C 函式庫是不是定義了由 time() 這個 C 函式庫使用的 time_t 資料型別。完成測試後 `configure' 指令稿會把結果包裝成建置時期可以存取的型式，以供建置時使用。

This chapter explains how to invoke a `configure' script from the perspective of a user -- someone who just wants to take your package and compile it on their system with a minimum of fuss. It is because Autoconf works as well as it does that it is usually possible to build a package on any kind of machine with a simple configure; make command line. The topics covered in this chapter include how to invoke configure, the files that configure generates and the most useful `Makefile' targets -- actions that you want make to perform -- that will be available when compiling the package (see section 4. Introducing `Makefile's).

在這章，我們會從使用者 -- 也就是想在他自己的系統上取得你的套件並編譯，但不希望碰上大麻煩的那個人 -- 的角度來解釋怎麼執行 `configure' 指令稿。拜 Autoconf 的精良實作，我們通常可以在任何機器上執行簡單的 configure; make 指令來進行套件的建置。我們會在這章討論怎麼執行 configure，哪些檔案會被 configure 產生，以及一些在編譯套件時很有用的 `Makefile' 建置目標 -- 也就是你想要 make 進行的動作 (請參閱 4. 簡介 `Makefile')。

Microsoft Windows

2.6 Microsoft Windows / Microsoft Windows

In 1995, Microsoft released Windows 95, which soon became the most widely-used operating system in the world. Autoconf and Libtool were written to support portability across Unix variants, but they provided a framework to support portability to Windows as well. This made it possible for a program to support both Unix and Windows from a single source code base.

Microsoft 的 Windows 95 在 1995 年上市後，很快的變成世界上被廣泛使用的作業系統。 Autoconf 與 Libtool 除了提供在各種 Unix 分支版本的可攜性支援外，也提供了延伸可攜性支援到 Windows 上的程式設計框架，這使得透過單一份原始碼來同時支援 Unix 與 Windows 成為可能的事情。

The key requirement of both Autoconf and Libtool was the Unix shell. The GNU bash shell was ported to Windows as part of the Cygwin project, which was originally written by Steve Chamberlain. The Cygwin project implements the basic Unix API in Windows, making it possible to port Unix programs directly.

Autoconf 與 Libtool 都需要 Unix shell 程式，而 GNU bash shell 恰被作為 Cygwin 計畫的一部分移植到 Windows 上。 Cygwin 計畫是由 Steve Chamberlain 所發起的，這個計畫在 Windows 上實做了基本的 Unix API ，使得 Unix 程式可以直接的移植到 Windows 上。

Once the shell and the Unix make program (also provided by Cygwin) were available, it was possible to make Autoconf and Libtool support Windows directly, using either the Cygwin interface or the Visual C++ tools from Microsoft. This involved handling details like the different file extensions used by the different systems, as well as yet another set of shared library features. This first version of this work was by Ian Lance Taylor in 1998. Automake has also been ported to Windows. It requires Perl to be installed (see section A.1 Prerequisite tools).

在 shell 與 Unix 的 make 程式都被移植到 Windows 上之後，便可以讓 Autoconf 與 Libtool 透過 Cygwin 或是 Microsoft Visual C++ toolkit 直接的支援 Windows。增加 Windows 支援牽涉到處理一些在不同的作業系統上細節，例如處理不同的檔案延伸名稱以及額外的共享函式庫功能，第一個可以支援 Windows 的版本在 1998 年由 Ian Lance 所開發。除此之外 Automake 也被移植到 Windows 上，他需要 Perl 預先安裝在系統上 (參見 A.1 需預先安裝的工具) 。

處理 Fink 搭配 subclipse 找不到 JavaHL 的設定

Fink 安裝的位置是 /sw 目錄，不是一個非常公認的地方，所以預設的搜尋路徑是找不到要找的東西的。

修正方法有兩種，我是直接改到 eclipse.ini 裡去，並沒有另外弄個 wrapper script 來處理。

要加入的內容如下

-Djava.library.path=.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:/sw/lib

前面一大串是預設直，在未作任何變動前應該可以從 About Eclipse Platform 的 Configuration 列表之中找到。

把 eclipse workspace 放在 netatalk AFP volume 上的額外設定

因為 netatalk 還不支援 file locking 所以會造成一點問題，要繞過這個問題就是把 locking mechanism 關掉就好了。

一樣是在 eclipse.ini 動手腳，在檔案末端加上下面這個設定即可。

-Dosgi.locking=none

在 Fedora7 上的 nss-mdns

nss-mdns 是 linux 上的 Zeroconf mDNS 解析器，主要功能是界接 glibc 與 Avahi 的名稱解析模組。

套件可以在 Fedora 的 Koji 中找到，或是很多第三方套件網站也有。

在 Mac OS X 的 Terminal.app 下在遠端 screen 無法使用 backspace

狀況是這樣子，在 Mac OS X 的終端機裡，連線到遠端的主機後，在遠端主機執行的 screen 會不理會 backspace 鍵。

我在 debian 上遇到這個問題，其他的 distribution 可能也會有這個問題，不過我不確定。

基本上原因就是 Terminal.app 送出的終端機識別字串沒有被識別，解決方法有修改終端機識別字串，或是有點掩耳盜鈴似的告訴 screen 應該怎麼識別終端機。

修改終端機識別字串，在 Mac 上執行這個指令:

defaults write com.apple.Terminal TermCapString xterm

覆寫掉遠端的終端機名稱描述，在遠端主機執行這個指令:

export TERM=xterm

或是，我是把下面這個丟到 .bashrc 裡:

alias screen ='TERM=xterm screen'

Libtool 的發展

2.5 Libtool Development / Libtool 的發展

Over time, Unix systems added support for shared libraries.

隨著時間的推移，Unix 系統加入了共享函式庫的支援。

Conventional libraries, or static libraries, are linked into a program image. This means that each program which uses a static library includes some or all of the library in the program binary on disk.

傳統的函式庫，或稱為靜態函式庫，會直接連結到程式檔之中。這表示，每個使用靜態函式庫的程式，會把所使用的函式庫的部份或全部複製到位於磁碟上的程式機械碼檔案之中。

Shared libraries, on the other hand, are a separate file. A program which uses a shared library does not include a copy of the library; it only includes the name of the library. Many programs can use a single shared library.

另一方面，共享函式庫則是分離的檔案。使用了共享函式庫的程式不需把函式庫的內容複製到程式內部；僅需在程式檔案內記錄函式庫的名字。數個程式可以使用一個共享函示庫。

Using a shared library reduces disk space requirements. Since the system can generally share a single executable instance of the shared library among many programs, it also reduces swap space requirements at run time. Another advantage is that it is possible to fix a bug by updating the single shared library file on disk, without requiring all the programs which use the library to be rebuilt.

使用共享函式庫可以減少磁碟空間的使用需求。此外，在執行時系統可以讓多個程式共用一份共享函式庫的執行實體，因此也可以減少執行時期所需的記憶體分頁暫存空間需求。另外一個好處是，修正函式庫的臭蟲只需更新一份共享函式庫的檔案，而不需重新建置所有有用到函式庫的程式。

The first Unix shared library implementation was in System V release 3 from AT&T. The idea was rapidly adopted by other Unix vendors, appearing in SunOS, HP-UX, AIX, and Digital Unix among others. Unfortunately, each implementation differed in the creation and use of shared libraries and in the specific features which were supported.

第一個 Unix 的共享函式庫實作是在 AT&T 的 System V release 3 之中。這個概念很快的被其他 Unix 廠商採用，在 SunOS, HP-UX, AIX, 與 Digital Unix 等等都可以見到。遺憾的是，每個實作在函式庫的建立、使用與所支援的功能上都有些許的不同。

Naturally, packages distributed as source code which included libraries wanted to be able to build their own shared libraries. Several different implementations were written in the Autoconf/Automake framework.

很自然的，含有函式庫的原始碼套件會需要建置他們自己的共享函式庫。在 Autoconf/Automake 程式設計框架下，有好幾個不同的實作被撰寫出來。

In 1996, Gordon Matzigkeit began work on a package known as Libtool. Libtool is a collection of shell scripts which handle the differences between shared library generation and use on different systems. It is closely tied to Automake, although it is possible to use it independently.

在 1996 年，Gordon Matzigkeit 開始製作一個稱為 Libtool 的套件。 Libtool 是一組 shell 指令稿，用來應付在不同系統上產生與使用共享函式庫的差異。 Libtool 是針對 Automake 而製作的，但也可以被獨立的使用。

Over time, Libtool has been enhanced to support more Unix variants and to provide an interface for standardizing shared library features.

隨著時間的推移，Libtool 現在可以支援比剛發表時更多的 Unix 衍伸系統，並且也提供了一個標準化的界面來操作共享函式庫。

Automake 的發展

2.4 Automake Development / Automake 的發展

By 1994, Autoconf was a solid framework for handling the differences between Unix variants. However, program developers still had to write large `Makefile.in' files in order to use it. The `configure' script generated by autoconf would transform the `Makefile.in' file into a `Makefile' used by the make program.

在 1994 年時，對於處理各 Unix 分支版本間的差異，Autoconf 已能提供一個完整並可靠的程式設計框架。然而，為了使用 Autoconf，程式設計師得寫幾個巨大的 `Makefile.in' 檔案。由 autoconf 產生出的 `configure' 指令稿會把 `Makefile.in' 轉換成給 make 程式使用的 `Makefile' 檔案。

A `Makefile.in' file has to describe how to build the program. In the Imake equivalent of a `Makefile.in', known as an `Imakefile', it is only necessary to describe which source files are used to build the program. When Imake generates a `Makefile', it adds the rules for how to build the program itself. Later versions of the BSD make program also include rules for building a program.

程式設計師得在 `Makefile.in' 中描述建置程式的方法。在 Imake 中，類似的工作由 `Imakefile' 擔當，但在 `Imakefile' 中只需要列出建置程式所需要的原始碼檔案。當 Imake 產生 `Makefile' 時，他會自動將所需的程式建置規則加進去。在比較晚近的 BSD make 中，也內含有建置程式用的建置規則。

Since most programs are built in much the same way, there was a great deal of duplication in `Makefile.in' files. Also, the GNU project developed a reasonably complex set of standards for `Makefile's, and it was easy to get some of the details wrong.

由於大部分的程式建置方法都一樣，因此在 `Makefile.in' 中有不少的內容是重複的。此外，GNU 計畫發展出了一組規範撰寫 `Makefile' 應依循的標準，這個標準相當的複雜，很容易把一些細節搞錯。

These factors led to the development of Automake. automake, like autoconf, is a program run by a developer. The developer writes files named `Makefile.am'; these use a simpler syntax than ordinary `Makefile's. automake reads the `Makefile.am' files and produces `Makefile.in' files. The idea is that a script generated by autoconf converts these `Makefile.in' files into `Makefile's.

這些種種不便開啟了 Automake 的發展，如同 autoconf 一樣，automake 也是給程式設計師使用的工具。程式設計師先用一套比一般的 `Makefile' 還精簡的語法撰寫 `Makefile.am' 檔案，接著執行 automake 來讀取 `Makefile.am' 並依據其內容產生 `Makefile.in' 檔。如此一來，所產生出來的 `Makefile.in' 檔便可以交給 autoconf 產生的指令稿來產生出 `Makefile' 檔案。

As with Imake and BSD make, the `Makefile.am' file need only describe the files used to build a program. automake automatically adds the necessary rules when it generates the `Makefile.in' file. automake also adds any rules required by the GNU `Makefile' standards.

就像 Imake 與 BSD make 一樣，在 `Makefile.am' 中只需要描述有哪些原始碼檔案會用來建置程式。在產生 `Makefile.in' 檔時 automake 會自動加入必要的規則，此外，automake 也會加入在 GNU 的 `Makefile' 標準中所要求的規則。

The first version of Automake was written by David MacKenzie in 1994. It was completely rewritten in 1995 by Tom Tromey.

第一版的 Automake 是 David MacKenzie 在 1994 年所撰寫。並在 1995 年，由 Tom Tromey 重新撰寫。

在 debian 上準備給 Mac 用的 AFPd

簡單講就是安裝 netatalk 這個套件，設定一下就一切搞定。

問題在於，在 debian 內附的 netatalk 不支援認證時加密，因為 OpenSSL 的授權跟 GPL 有所衝突的關係。這實在是很無聊的理由... 不過總之就是這樣。

因此，就得自己編譯 netatalk 套件。方法跟這篇講的一樣，基本上就是安裝額外的相依套件，然後照著一般的建置程序做就可以了。

cd /usr/src
apt-get install openssl libssl-dev cracklib2 libpam-cracklib cracklib2-dev
apt-get source netatalk
apt-get build-dep netatalk

然後編輯建置規則檔

cd netatalk-2.0.3
vi debian/rules

在大概第 18 行附近找到 ##FIXME: Other changes are needed, like enabling DHX plugin 的字樣，把 DEB_BUILD_OPTIONS=ssl debuild 加進去。

最後執行 dpkg-buildpackage 就會開始製作套件檔，做完用 dpkg -i 安裝就完成了。

接著再修改 /etc/default/netatalk 設定檔，我改了 UAMLIST 並且關掉 AFPD 跟儲存 meta data 用的 CNID 之外的服務。主要是把 ATALKD 跟 PAPD 關掉，其他沒動應該也是無所謂。

AFPD_UAMLIST="-U uams_dhx.so,uams_randnum.so"

ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

再來就是參考這邊，修改 /etc/netatalk/afpd.conf 設定，主要是把 AppleTalk 關掉，走 TCP 就好了。

- -noddp -uamlist uams_randnum.so,uams_dhx.so

然後新增 Avahi 的服務描述檔，這樣就可以直接用 Bonjor 找到機器。

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">

<service-group>

  <name replace-wildcards="yes">AFP on %h</name>

  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>

</service-group>

該重啟動的重啟動之後，應該就可以用了。

另外還可以在 /etc/netatalk/AppleVolumes.default 加上 option:usedots,noadouble 讓一些 netatalk 用來儲存 Mac 特殊檔案狀態用的檔案名稱不會被編碼，而可以藏起來。

Configure 的發展

2.3 Configure Development / Configure 的發展

The Cygnus `configure' script and the original GCC `configure' script both had to be updated for each new Unix variant they supported. This meant that packages which used them were continually out of date as new Unix variants appeared. It was not hard for the developer to add support for a new system variant; however, it was not something which package users could easily do themselves.

Cygnus 的 `configure' 指令稿與 GCC 原始的 `configure' 指令稿都必須針對所支援的 Unix 衍生作業系統做出修改，這代表當新的 Unix 衍生作業系統出現時，使用了這兩樣工具的軟體套件必須修改才能用在新的作業系統上。對於軟體的發展者而言，修改軟體套件以支援新的作業系統可能並非難事；但是對於軟體套件的使用者而言，這就不是件容易自己搞定的事情。

The same was true of Imake as it was commonly used. While it was possible for a user to build and configure Imake for a particular system, it was not commonly done. In practice, packages such as the X window system which use Imake are shipped with configuration information detailed for specific Unix variants.

被漸漸廣泛使用的 Imake 也面臨一樣的問題，雖然使用者自己針對特定系統建置並設定 Imake 不是難到不可能的事，但其實很少使用者這麼做。在實務上，像 X window 這類使用 Imake 的軟體套件，會帶有針對各個不同的 Unix 衍生作業系統所撰寫的配置檔。

Because Metaconfig and Autoconf used feature tests, the scripts they generated were often able to work correctly on new Unix variants without modification. This made them more flexible and easier to work with over time, and led to the wide adoption of Autoconf.

因為 Metaconfig 與 Autoconf 是利用一序列的測試來決定系統提供的功能，因此所產生的組態指令稿通常不用修改就能在新的 Unix 衍生作業系統上正確執行。這樣的特性讓這兩項工具被視為具彈性且不用頻繁維護的方案，並使 Autoconf 被大量採用。

In 1994, David MacKenzie extended Autoconf to incorporate the features of the Cygnus `configure' script and the original GCC `configure' script. This included support for using system specified header file and makefile fragments, and support for cross-compilation.

在 1994 年 David MacKenzie 將 Autoconf 加以擴充，納入了 Cygnus 的 `configure' 指令稿與原始的 GCC `configure' 指令稿的功能。這次擴充使 Autoconf 支援針對不同系統使用不同的標頭檔或 makefile 檔案片段，另外也支援了跨平臺編譯。

GCC has since been converted to use Autoconf, eliminating the GCC `configure' script. Most programs which use the Cygnus `configure' script have also been converted, and no new programs are being written to use the Cygnus `configure' script.

從此之後，GCC 便轉而使用 Autoconf 並揚棄了原本的 GCC `configure' 指令稿。大多數使用 Cygnus `configure' 指令稿的程式也改用 Autoconf，新的程式也不再使用 Cygnus `configure' 指令稿。

The metaconfig program is still used today to configure Perl and a few other programs. imake is still used to configure the X window system. However, these tools are not generally used for new packages.

Metaconfig 在今日仍被用在 Perl 與幾個其他程式的建置中進行組態工作，Imake 也仍被用來組態 X window 系統。但是，在新的軟體套件中就很少會去使用這些工具了。

twitter

鈍鈍的，大概是 AJAX 用太兇了。

實在是沒想到有什麼用，以後 imbot 有什麼動作的話，就丟上去好了，性質似乎蠻合的。

在 OS X 上裝 CPAN module

沒有想像中可怕，不過 HFS+ 的不分辨大小寫功能的確是會造成問題。

找到這篇文章提到，重點在於設定 cpan 的時候，要讓他把 "INSTALLBIN=/usr/local/bin INSTALLSCRIPT=/usr/local/bin" 設為 perl Makefile.PL 的參數。

從 which 來看，用的應該還是原本 OS X 的 perl 程式，不過 fink 會把 library 的目錄讓他先去搜尋 fink 的 lib 目錄，這是比較稍微有點讓人擔心的地方，其他都蠻正常的。

裝電腦或修電腦這件事

最近又開始有人找我幫忙電腦的問題，不知道是不是天氣冷了，於是大家與電腦接觸的時間長了，就開始有一些怨言。

基本上就是不幫忙，我處理這幾件事的重點是:

裝電腦

原則上，我是不會特地幫忙裝電腦或買電腦，除非我自己剛好也有要買，或是周遭剛好有要出採購團。

列零件配備的話，也是抱歉，不過這裡有張我之前列的表，可以參考看看。這個表有一段時間了就是，大概只能參考牌子吧！

要買電腦，然後自己沒有辦法組裝或挑零件的話，其實我是比較建議買品牌電腦。因為或多或少會有需要維修的時候，有的品牌有提供到府收送，這樣會方便很多，不用自己累得半死搬到店家去。

至於建議的牌子，桌上型的話: ASUS, Dell 。要注意的是，如果是 ASUS 的話，不是所有代理商都有提供到府收送，這是要注意的地方。 Dell 的話，到府收送是一個搭配不同的處理時間保證的選購項目，要弄清楚。

筆記型電腦的話: ASUS 。主要是東西相較之下不是太貴，國內維修點也多。如果要出國的話，可能要看各廠牌對你去的國家維修支援的狀況，問問當地人會比較好。

很多人會問日系品牌到底好不好，就我看，日系機器不見得品質有多好到哪去，尤其有些中低價位的型號根本是委託臺灣廠設計，考量到使用壽命與價格不見得會比較值得。

修電腦

基本上，我並不幫忙修電腦，除非是我的程式的問題，否則我不處理也不檢視。

這種事情我是覺得，女人自己不會修可以去找自己的男人，基本上是男人就應該會修電腦，找不到會修電腦的男人的話，也還是可以上店家花點錢處理。把這種成本轉嫁到無關的人身上，並且沒有相對的報酬，實在蠻過分的。

灌電腦

這個，同上，請自行想辦法處理。

說實在的啦！找認識的人處理電腦問題，十之八九也只是為了免費而已，甚至有的人還會多方徵詢意見，弄了半天結果一點也沒派上用場，感覺實在是挺差的。

「時代已經不同了，這年頭癡情的只有被發卡的份而已。」這是在一篇頗無聊的文章內看到的話，從某種角度而言，這句話道盡了人際關係間的現實啊！

說到修電腦這檔事，主要牽涉到的就是時間與金錢。處理要時間，如果有硬體壞了差不多就得要錢。

雖然時間耗的是出手修的人的時間，不過還是得看找人來修的那位的心態如何。有個朋友，姑且稱之為宅宅好了，去幫一位認識的女生修電腦，好像有個系統檔被置換掉了，總之就是弄很久才解決，花了一整個下午吧！

後來聽熟悉內部情報人士透露，這個下午那個女生的男朋友來找她，總之女生怕宅宅不高興，於是這個男生就被支在外面。後來，女生這邊抱怨說電腦弄的太久了，本來那整個下午她要跟她男友好好翻雲覆雨一翻，結果卻得陪這個宅宅。

比較麻煩的是，通常大家都有很多活動，所以一些要花長時間找的問題就比較尷尬。看到問題，處理好也不是，不處理好又是一個疙瘩。

金錢方面相對是小事，只是算起來還是不太好看，通常我會告訴他們可能是哪個東西壞了，叫他們整台抱去檢修看看。當然，也是有人請我代購，不過有過一次經驗，千里迢迢從號稱實際售價最便宜的光華商場買回來，然後被嫌貴。比較誇張的是，買回來換上去兩三個月後，跟我抱怨現在買比較便宜... 碼的，明年買的話同樣價格功能還更棒咧！

簡言之，不論是就金錢，還是時間而論，修電腦都是件吃力不討好的蠢事。

裝電腦大概比修電腦好一點，至少比較不會遇到那種很怪異難解的問題，不過一樣是浪費時間。一開始可能至少會對搞定系統有點成就感，久了就會對插插拔拔膩了，雖然其實都是小事。

所以，現在我就不太幫修電腦、裝電腦、重裝諸如 Windows, Office 之類的軟體... 花時間，花下去看到的都是負面的，沒什麼實際的好處。

要說對人際關係有什麼好處，我是沒看到啦！會找的那些人，難得有事來找就是修電腦，要玩要幹嘛並是不會來找。

當然，也是因為玩樂的事情來找也玩不起來就是，講白了，根本就不熟啊！熟的，平常出去吃飯打混，電腦有問題問個兩句就解決了，有什麼重要的情報也直接交換，反而感覺上並不太會有需要處理電腦相關事務的時候。

Bonjour on Windows

這東西在標準的名稱是 Zeroconf ，不過各家廠商有各家的叫法。 Apple 算是最誇張的吧！完全抹掉 Zeroconf 這個名字。

總之，對於小型的區域網路來講，的確蠻方便的。主機安裝時都會設有名稱，裝了之後，就可以利用這個名稱轉換成 Zeroconf 的 .local 網域名稱。

在 Windows 上 Apple 有提供 Bonjour for Windows 給 Windows 使用，試了一下，的確可以順利的使用 .local 來完成名稱正解。