keremet/rpm-ostree
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
80dc572514
rpm-ostree/Makefile-lib.am

66 lines
2.7 KiB
Plaintext
Raw Normal View History

Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
# Makefile for C source code
#
# Copyright (C) 2015 Colin Walters <walters@verbum.org>
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with this library; if not, write to the
# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
include Makefile-lib-defines.am
lib_LTLIBRARIES += librpmostree-1.la
librpmostreeincludedir = $(includedir)/rpm-ostree-1
librpmostreeinclude_HEADERS = $(librpmostree_public_headers)
librpmostree_1_la_SOURCES = \
lib: Expose new API around basearch For https://pagure.io/atomic-wg/issue/299 we need to make it more convenient to substitute the architecture in an installation context. I plan to use this API inside `rpmostreepayload` in Anaconda, so we can substitute the same value of `${basearch}` we use in treefiles since https://github.com/projectatomic/rpm-ostree/pull/305 Now, you might wonder - why do we need an API wrapping libdnf? It's because libdnf is not API stable yet. We're just exposing a tiny subset. In theory we could use the Python dnf bindings in Anaconda, but things get slightly weird if rpmostreepayload depends on dnf. Perhaps we'll do that down the road, but for now this a small API surface to maintain (forever). This change reworks the internal `varsubst` bits to take a pure `DnfContext`, since we don't want to spin up a whole `RpmOstreeContext` just to do some string substitutions. Closes: #877 Approved by: jlebon
2017-07-13 23:39:01 +03:00
src/lib/rpmostree.c \
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
src/lib/rpmostree-db.c \
lib: Add RpmOstreePackage The `QueryResult` class ended up being too awkward; having NEVRA strings meant for example that clients would have to parse them. It would be harder to present something like the current `rpm-ostree upgrade` package diff output. Now...I debated quite a while before doing this patch. The thing that's really awful about creating this library is there are *SO MANY* layers. rpm-ostree → libhif → hawkey → libsolv → librpm. It's enough to make one question whether one is actually accomplishing anything or just contributing to a collective insanity... Let's pretend for now it's the former. Closes: https://github.com/projectatomic/rpm-ostree/pull/136
2015-04-16 05:20:57 +03:00
src/lib/rpmostree-package.c \
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
$(NULL)
librpmostree_1_la_CFLAGS = $(AM_CFLAGS) -I$(srcdir)/libglnx -I$(srcdir)/src/libpriv -I$(srcdir)/src/lib \
build: Use -fvisibility=hidden and explicit exports This avoids symbol leakage. Previously we were at risk of exporting other random API from libpriv, as well as libglnx.
2015-04-14 04:25:05 +03:00
-fvisibility=hidden '-D_RPMOSTREE_EXTERN=__attribute((visibility("default"))) extern' \
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
$(PKGDEP_RPMOSTREE_CFLAGS)
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
librpmostree_1_la_LDFLAGS = $(AM_LDFLAGS) -version-number 1:0:0 -Bsymbolic-functions
lib: Drop dependencies on internal librpmostree-priv A long time ago now we started injecting the package list into the ostree commit. We were carrying backwards compatibility code to do a checkout of an ostree commit and extract it, but if we delete that and have it return an error, it removes the last bits that end up calling into our internal librpmostreepriv.la. Now the internal shared library only links to our private `libdnf.so.2`, `libglnx.la` statically, and libglib.so and libostree.so. In the future it'd be nice to even drop the linkage to `libdnf.so.2` because that drags in a lot of stuff, and I suspect e.g. gnome-software may hit incompatibilities if it also links in the "system" libdnf.
2020-12-16 23:26:03 +03:00
librpmostree_1_la_LIBADD = $(PKGDEP_RPMOSTREE_LIBS) libglnx.la
EXTRA_librpmostree_1_la_DEPENDENCIES = libdnf.so.2
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
Makefile.am: Link with --enable-new-dtags When g-ir-scanner runs, it uses a stub binary to help introspect the target rpm-ostree library. That binary needs to link to the library, and of course, transitively, to our bundled libdnf. Since we run the scanner uninstalled, we use `LD_LIBRARY_PATH` to point the stub at the libdnf from the build directory. When we compile rpm-ostree, we use `-rpath` to point it at our libdnf, which emits a `DT_RPATH` attribute. However, during dynamic linking at runtime, it turns out that `LD_LIBRARY_PATH` has *lower* precedence than `DT_RPATH`. This means that if there is already a libdnf at `/usr/lib64/rpm-ostree`, it takes precedence. This subtlety is mostly fine to ignore usually, because the stub doesn't actually run any rpm-ostree business logic, so it doesn't really matter that it runs against the "technically wrong" `libdnf.so.2`. Where it becomes obvious something is off however is if we've just built a new libdnf, and we have new code which references symbols from the new libdnf that aren't in the stale libdnf at `$libdir/rpm-ostree`. And this is exactly what was happening in CI (though it's of course possible to reproduce this locally as well): we were using a new symbol, `hy_goal_favor`, and building inside the cosa buildroot image, which already has rpm-ostree installed, and so `ld.so` chose the bundled libdnf of the installed rpm-ostree when loading the `g-ir-scanner` stub. Thus why it failed with: ``` ./tmp-introspectzh0n2cga/.libs/lt-RpmOstree-1.0: symbol lookup error: .libs/librpmostree-1.so.1: undefined symbol: hy_goal_favor ``` And of course, the root cause here has nothing to do with the stub in itself. It's actually trivially easy to see the behaviour difference wrt `LD_LIBRARY_PATH` on installed binaries. Using a shared object from `python3-libdnf` which links to libdnf without using rpath, we can see that `LD_LIBRARY_PATH` has an effect: ``` $ ldd /usr/lib64/python3.7/site-packages/libdnf/_transaction.so | grep libdnf libdnf.so.2 => /lib64/libdnf.so.2 (0x00007fdde789e000) $ LD_LIBRARY_PATH=./libdnf-build/libdnf ldd /usr/lib64/python3.7/site-packages/libdnf/_transaction.so | grep libdnf libdnf.so.2 => ./libdnf-build/libdnf/libdnf.so.2 (0x00007fa615048000) ``` Whereas with rpm-ostree: ``` $ ldd /usr/bin/rpm-ostree | grep libdnf libdnf.so.2 => /usr/lib64/rpm-ostree/libdnf.so.2 (0x00007f7da5271000) $ LD_LIBRARY_PATH=./libdnf-build/libdnf ldd /usr/bin/rpm-ostree | grep libdnf libdnf.so.2 => /usr/lib64/rpm-ostree/libdnf.so.2 (0x00007fc905dbd000) ``` And going further down the rabbit hole, `DT_RPATH` is in fact considered deprecated for this reason; it makes it harder to run with uninstalled libraries or whatever reason one has to want to override a library (one can still use `LD_PRELOAD`, though the semantics are different, and it's less commonly used than `LD_LIBRARY_PATH`). Instead, we should use `DT_RUNPATH`, which does have lower precedence than `LD_LIBRARY_PATH`, matching the usual behaviour. To make the linker emit `DT_RUNPATH` attributes, we have to use the `--enable-new-dtags` flag. This also then fixes the g-ir-scanner issue described above.
2020-05-11 21:08:45 +03:00
# The g-ir-scanner creates a stub executable (to help introspect type information) which
# links to our stuff. We want to make sure it picks up our fresh libdnf and not a possibly
# stale one from a previously installed rpm-ostree's bundled libdnf.
Update for libhif -> libdnf Still not many PRs outstanding, so it's a good time to take this plunge. Mostly automated via `sed`. Closes: #416 Approved by: Conan-Kudo
2016-08-03 21:30:17 +03:00
INTROSPECTION_SCANNER_ENV = env LD_LIBRARY_PATH=$(top_builddir)/libdnf-build/libdnf
Switch to using libhif as a git submodule So I was trying to hack on my host's copy of rpm-ostree inside a pet docker container, but ran into a conflict with libhif since dnf uses it. I think we basically need to *always* build the bundled path, rather than what I'm doing with CAHC and FADC where it's built as a regular RPM. It's not really sustainable right now for us to have both bundled and not-bundled build paths - and we need to support co-installation with dnf. Another major issue is that we want to version lock with libhif - right now our CI and both CAHC/FADC track libhif master, but that means everything breaks if libhif breaks and we don't immediately port. git submodules solve all of these problems - the same as we're doing with libglnx. libglnx is *designed* for use as a git submodule, where as libhif needs to support being both bundled and not-bundled. So we end up with some hacks on our side, but I think it's all not too bad. I've marked build rules with `# bundled libhif` so we know where to find them later when libhif is stable. Closes: #357 Approved by: jlebon
2016-06-29 04:33:02 +03:00
Makefile-libs.am: Work around `g-ir-scanner` issues with clang Right now there's an issue in Fedora with `g-ir-scanner` picking up `-fstack-clash-protection` from the `sysconfig` Python module and passing it to `clang`, which doesn't understand this flag yet. Just work around this by (1) not even building GIR bindings for our bundled libdnf since there's no need, and (2) overridding the compiler used by `g-ir-scanner` so it's always `gcc`. See: https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585 Closes: #1787 Approved by: cgwalters
2019-03-18 19:11:14 +03:00
# XXX: work around clang being passed -fstack-clash-protection which it doesn't understand
# https://github.com/projectatomic/rpm-ostree/pull/1787#issuecomment-473971585
INTROSPECTION_SCANNER_ENV += CC=gcc
Add a public shared library, with "rpm -qa" for commit functionality This will help build release engineering and other types of tools; for example, rather than parsing the output of `db diff`, one should be able to call an API. Initially, this adds the generic infrastructure for a public shared library, with a new function call to do the equivalent of `rpm -qa` on a particular OSTree commit. Closes: https://github.com/projectatomic/rpm-ostree/issues/117 Closes: https://github.com/projectatomic/rpm-ostree/pull/124
2015-03-20 03:45:30 +03:00
if BUILDOPT_INTROSPECTION
RpmOstree-1.0.gir: librpmostree-1.la Makefile
RpmOstree_1_0_gir_EXPORT_PACKAGES = rpm-ostree-1
RpmOstree_1_0_gir_INCLUDES = OSTree-1.0 Gio-2.0
RpmOstree_1_0_gir_CFLAGS = $(librpmostree_1_la_CFLAGS)
RpmOstree_1_0_gir_LIBS = librpmostree-1.la
RpmOstree_1_0_gir_SCANNERFLAGS = --warn-all --identifier-prefix=RpmOstree --symbol-prefix=rpm_ostree
RpmOstree_1_0_gir_FILES = $(librpmostreeinclude_HEADERS) $(filter-out %-private.h,$(librpmostree_1_la_SOURCES))
INTROSPECTION_GIRS += RpmOstree-1.0.gir
gir_DATA += RpmOstree-1.0.gir
typelib_DATA += RpmOstree-1.0.typelib
CLEANFILES += $(gir_DATA) $(typelib_DATA)
endif
pkgconfig_DATA += src/lib/rpm-ostree-1.pc
Reference in New Issue Copy Permalink