IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Having slept on it, I've realised that baking the dependency CFLAGS into
the pkg-config file is pointless when it is only used to link against
them. It may even cause problems.
pkg-config supports `Requires.private` and `Libs.private` fields for
static linking. However, if you're building a dynamic binary, then
pkg-config will use the non-private fields, even if just the static
libxml2 is available. This will result in libxml2 being underlinked,
causing the build to fail. The solution is to fold the private fields
into the non-private fields when the shared libxml2 is not being built.
This works for Autotools and CMake. Meson also knows how to handle this
when it automatically generates pkg-config files.
The -I and -L flags you use to build should not necessarily be the same
ones you bake into installed files. If you are building with
dependencies located under a SYSROOT then the installed files should
have no knowledge of that SYSROOT. For example, if the build requires
`-L/path/to/sysroot/usr/lib/foo` then only `-L/usr/lib/foo` should be
baked into the installed files.
pkg-config is SYSROOT-aware, so this issue can be sidestepped by using
the `Requires` field rather than the `Libs` and `Cflags` fields. This is
easily resolved if you rely solely on pkg-config, but this project falls
back to standard Autoconf checks, so a little more effort is required.
Unfortunately, this issue cannot feasibly be resolved for CMake.
`find_package` is used rather than `pkg_check_modules`, so we cannot
tell whether a pkg-config file for each dependency is present or not,
even if `find_package` uses pkg-config behind the scenes. The CMake
build does not record any dependency -I or -L flags into the pkg-config
file anyway. This is a problem in itself, although these dependencies
are most likely installed to standard locations.
Meson is very much better at handling this, as it generates the
pkg-config file automatically using the correct logic.
If libxml2 is built and linked against liblzma, the latter needs to appear in
libxml2’s Libs.private pkg-config field, otherwise static linking against
libxml2 will fail due to unresolved liblzma symbols.
https://bugzilla.gnome.org/show_bug.cgi?id=711026
For https://bugzilla.gnome.org/show_bug.cgi?id=677606
For https://bugs.gentoo.org/show_bug.cgi?id=417539
If libxml2-2.8.0 is built with --with-icu --with-python on a system that has an
older version of libxml2 installed, then during "make install", libxml2mod.so
gets relinked to the systemwide version of libxml2.so.2 instead of libxml2.so.2
from the build tree, and fails at runtime if symbol versions from the older
libxml2.so.2 are not available. This effectively makes it impossible to build a
libxml2-2.8.0 binary package on a system that does not already have
libxml2-2.8.0 installed.
Investigation by Rafał Mużyło and Arfrever Frehtes Taifersar Arahesis revealed
the cause of the problem to be that libxml2's configure was adding ICU_LIBS to
LDFLAGS instead of to LIBADD. This resulted in GNU libtool using the wrong
argument order in its relinking command that gets run during "make install".
The libxml-2.0.pc file doesn't contain the win32 specific libraries. So when
(cross-)compiling for Windows, the output of
pkg-config libxml-2.0 --libs
returns an incompile set of libraries. Thus, applications using libxml2's
network functionality fail to build for the win32 platform.
* libxml-2.0.pc.in: applied patch from Mikhail Zabaluev to separate
library flags for shared and static builds, fixes#344594. If this
bites you, use xml2-config.
Daniel
* config.h.in configure.in libxml.spec.in include/libxml/Makefile.am
libxml-2.0.pc.in: moved includes to includedir/libxml2/libxml,
updated the configuration scripts systems accordingly
Thu Feb 23 02:03:56 CET 2001 Tomasz Koczko <kloczek@pld.org.pl>
* *.c *.h libxml files: moved to libxml directory - this allow
simplify automake/autoconf. Now isn't neccessary hack on
am/ac level for make and remove libxml symlink (modified for this
also configure.in and main Makefile.am). Now automake abilities
are used in best way (like in many other projects with libraries).
* include/win32config.h: moved to libxml directory (now include
directory isn't neccessary).
* Makefile.am, examples/Makefile.am, libxml/Makefile.am:
added empty DEFS and in INCLUDES rest only -I$(top_builddir) -
this allow minimize parameters count passed to libtool script
(now compilation is also slyghtly more quiet).
* configure.in: simplifies libzdetestion - prepare separated
variables for keep libz name and path to libz header files isn't
realy neccessary (if someone have libz installed in non standard
prefix path to header files ald library can be passed as:
$ CFALGS="-I</libz.h/path>" LDFLAGS="-L</libz/path>" ./configure
* autogen.sh: check now for libxml/entities.h.
After above building libxml pass correctly and also pass
"make install DESTDIR=</install/prefix>" from tar ball generated by
"make dist". Seems ac/am reorganization is finished. This changes
not touches any other things on *.{c,h} files level.
2000-09-30 Martin Baulig <baulig@suse.de>
* libxml-2.0.pc.in: Provide pkg-config script.
* configure.in: Create the libxml-2.0.pc script from the
libxml-2.0.pc.in templates.
* Makefile.am (pkgconfig_DATA): Install the libxml-2.0.pc
script in `$(libexecdir)/pkgconfig'.
