TLPI 程式碼問答集
當使用提供的 makefile 編譯程式時，某些範例程式的“書籍”版本會產生以下編譯警告：
warning: "_XOPEN_SOURCE" redefined
要了解出現此警告的原因，需注意兩條有用的背景訊息：
- 本書中的所有原始碼範例都是寫出來的，因此它們預設會使用 GNU C 編譯器選項，或以下選項（對應於符合 SUSv3+C99 標準的編譯環境）進行編譯：$ cc -std=c99 -D_XOPEN_SOURCE=600
- 程式的 makefile 包含了啟用大多數可能警告的編譯器選項 (-pedantic -Wall -W)。
範例程式中使用的一些介面需要有定義 _XOPEN_SOURCE。如果使用這些介面的程式是用 -std=c99 -D_XOPEN_SOURCE=600 編譯的，那麼一切都很正常。但是，如果此類程式在編譯時沒有定義 _XOPEN_SOURCE ，但又如上所述那樣打開了警告選項，則會導致錯誤或警告（例如，諸如函數 “xxxxxx” 的隱含宣告之類的訊息）。
我為這些程式決定的解決方案是，包含一個預先處理器（preprocessor）#define 語句，它適當地定義了 _XOPEN_SOURCE。此解決方案的局限性在於，當使用 -D_XOPEN_SOURCE=600 編譯這些程式，並且原始檔案使用不同的值重新定義 _XOPEN_SOURCE 時，編譯器會發出有關重新定義的警告。
這兩個範例對於避免編譯器警告，示範了更完整的解決方案：
#ifndef _XOPEN_SOURCE
#define _XOPEN_SOURCE
#endif
#if ! defined(_XOPEN_SOURCE) || _XOPEN_SOURCE < 500
#define _XOPEN_SOURCE 500
#endif
由於代碼緊湊的原因，此方法未在「書籍」版本的程式碼中採用，但在「distribution」版本中會採用。
也可以參考 TLPI 書籍的 3.6.1 節。
如果您遇到錯誤 sys/acl.h: No such file or directory，那是因為您的系統上沒有安裝所需的 ACL套件。
在 Debian 或是 Ubuntu 系統，用如下的指令安裝應該會有用：
$ sudo apt-get install libacl1-dev
在使用 RPM 安裝套件的系統上，你會需要安裝 libacl-devel 套件。
如果你看到錯誤訊息「error sys/capability.h: No such file or directory」
這是因為你的系統沒有安裝所需的套件。在 Debian 或 Ubuntu 系統，你可以用下面的指令安裝看看，應該會有用：
$ sudo apt-get install libcap-dev
在使用 RPM 安裝套件的系統上，你會需要安裝 libcap-devel 套件。
如果你看到這個錯誤訊息「selinux/selinux.h: No such file or directory」，這是因為你的系統又有套件沒有安裝。在 Debian 或 Ubuntu 系統，你可以用下面的指令安裝看看，應該會有用：
$ sudo apt-get install libselinux1-dev
在使用 RPM 安裝套件的系統上，你會需要安裝 libselinux-devel 套件。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題二。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題二。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
有關編譯「書本」版本的程式碼時發生的「_XOPEN_SOURCE」重新定義警告的訊息，請參考問題一。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
如果你看到錯誤訊息「sys/capability.h: No such file or directory」，請參考問題三。
編譯此程式時，在使用 glibc 2.24 或更高版本編譯時，您可能會遇到警告 'readdir_r' is deprecated [-Wdeprecated-declarations]。 （我如何得知系統上的 glibc 版本呢？）這是因為自 glibc 2.24 以來 readdir_r() 已被棄用。有關詳細信息，請參閱第 357 頁的勘誤表。
編譯此程式的「book」版本時，若保留各種MS_*常數為未宣告，可能會發生錯誤。如果系統上的 GNU C 函式庫比2.12版舊時，就會發生此錯誤，因為舊版的 glibc 並未定義某些必要的常數。（如何找出系統上有哪個版本的glibc？）
解決的方法是在使用較新的 glibc 版本的系統上編譯程式，或是編譯程式的「distribution」版本。
變數 'rvar' 可能會被 'longjmp' 或 'vfork' 警告所阻擋，在編譯此程式時可預期出現該警告。GNU C 編譯器正是在準確診斷這個程式所示範的問題。請見這本書第137頁。
如果您遇到函式內不允許的 #pragma GCC 診斷錯誤，這是因為您使用的是舊版的 GNU C 編譯器，它不支援使用 #pragma 語法，因而程式若使用了 #pragma，則會導致編譯器發出警告。
如果可以，請升級至 gcc 4.6（2011年3月）或更新的版本。否則，請編輯程式，移除所有以 #pragma 開頭的那行程式碼並重新編譯（此時您會看到先前隱藏的警告訊息）。
如果發生錯誤 bits/wordsize.h：No such file or directory or sys/cdefs.h: No such file or directory。您執行 Linux 套裝版本 （例如Ubuntu或Debian）可能是需要安裝 gcc-multilib 套件，才能建置此程式的。類似下列的安裝動作應該能正常運作：
$ sudo apt-get install gcc-multilib
在 64 位元的系統上編譯時，您會看到有關指標與不同大小的整數之間的型別轉換警告。我應該在這個程式中使用 intptr_r 型別。但是，由於第 649 頁勘誤表末尾所談的原因，我選擇不對程式碼或文字進行任何的更改。
如果發生錯誤 selinux/selinux.h: No such file or directory, 請參考問題四。
在編譯此程式的書籍版本時，若出現警告重複定義 "_XOPEN_SOURCE", 請參考問題一。
For an explanation of the "_XOPEN_SOURCE" redefined warning that occurs when compiling the "book" version of this program, look here.
For an explanation of the "_XOPEN_SOURCE" redefined warning that occurs when compiling the "book" version of this program, look here.
哈囉！感謝您的詢問。有些讀者指出，在 TLPI 的第 58 頁上顯示的 lib/ename.c.inc 檔案在從書籍網站下載的程式碼 tarball 中並不存在。這是因為當在 lib 目錄（或原始碼的根目錄）中執行 make(1) 時，此檔案會透過腳本自動建立。請參閱 lib/Makefile，其中呼叫 Build_ename.sh。之所以採用這種方式，是因為錯誤名稱集可以因核心和 glibc 版本以及硬體架構而異。
To determine the version of the Linux kernel running on your system, use the following command:
$ uname -sr
Linux 5.10.23-200.fc33.x86_64
On a sufficiently recent system, you can determine the version of glibc running on your system using the following command:
$ getconf GNU_LIBC_VERSION
glibc 2.26
If that command doesn't work (perhaps because you have an older system), then you can obtain the glibc version by executing the library shared object. On many systems, this is as simple as the following:
$ /lib/libc.so.6
The first line of output of this command shows the glibc version on your system.
However, on some systems, glibc resides at a different path, so that the above command won't work. The following command obtains the pathname of the library by applying ldd to a dynamically linked executable at a known location, and then nests the resulting output inside command substitution to execute that pathname, producing the same results as the simpler command above.
$ ldd /bin/ls | grep libc.so | awk '{print $3}'
/lib/i386-linux-gnu/libc.so.6
$ $(ldd /bin/ls | grep libc.so | awk '{print $3}')
GNU C Library (GNU libc) stable release version 2.26, by Roland McGrath et al.
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 7.3.1 20180303 (Red Hat 7.3.1-5).
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>
You are compiling the code on a system that has glibc 2.20 or later installed. In glibc 2.20, the _BSD_SOURCE and _SVID_SOURCE feature test macros were deprecated. They continue to expose the definitions that they exposed in earlier glibc versions, but their use produces the warning noted above. Instead, the _DEFAULT_SOURCE macro should be used. The simplest fix for this problem is to download the latest code tarball, which fixes the problem by modifying the Makefile.inc file to add -D_DEFAULT_SOURCE to the definition of the IMPL_CFLAGS macro.
\
Last modified 7d ago