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 特殊檔案狀態用的檔案名稱不會被編碼，而可以藏起來。