Change the include path in the Cflags field so that #include
<lib/foo.h> and <foo.h> will work. We had originally used a C flags
which allowed <foo.h> to work, but many applications (especially those
not using pkg-config) had been using the <lob/foo.h> formulation which
didn't require an explicit -I{$includedir} option to the C compiler.
If those applications then converted over to pkg-config, and the
e2fsprogs libraries were installed with a prefix other than /usr, so
that the header files were in some directory such as
/usr/local/include, a program that used #include <lib/foo.h> would
fail to compile.
So change the pkg-config files to include both -I{$includedir} and
-I{$includir}/lib.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
compile_et puts #include <et/com_err.h> in
generated header files so pkg-config --cflags
com_err should provide the path to the directory
containing et/.
SuSE has been carrying a patch for a long time to prevent a largely
theoretical race condition if a multi-threaded application adds and
removes error tables in multiple threads. Unfortunately SuSE's
approach breaks compatibility by forcing applications to link and
compile with the -pthread option; using pthread mutexes has
historically been problematic.
This commit fixes things in a more portable way by using
sem_post/sem_wait instead, which is an older interface that doesn't
require the pthreads library. Linux happens to implement
sem_post/sem_init using futexes, and -lrt ends up pulling in
-lpthread, but the advantage of using POSIX semaphores is that
applications don't have to be built using -pthread, unlike the use of
pthread mutexes.
The add_error_table() and remove_error_table() interfaces are the
preferred interfaces and locking protection have been added to only
these interfaces. I have not added locking protection to the
generated initialize_xxx_error_table and initialize_xxx_error_table_r
interfaces, to avoid adding symbol dependencies that would cause a
library to fail to work when linking against older com_err libraries
that do not export et_list_lock() and et_list_unlock(). Threaded
applications shouldn't be using these interfaces in any case.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Theodore Ts'o