Skip to content
This repository has been archived by the owner on May 21, 2024. It is now read-only.

Switch to dynamic libraries #1512

Merged
merged 4 commits into from
Jan 9, 2020
Merged

Switch to dynamic libraries #1512

merged 4 commits into from
Jan 9, 2020

Conversation

lbonn
Copy link
Contributor

@lbonn lbonn commented Jan 8, 2020

Besides the obvious reuse we have between aktualizr and aktualizr-info, it might be time to ship libaktualizr as a standalone library.
For now, aktualizr_static_lib still exists, we might remove it at a later point.

This will also allow some simplifications in #1498.

Copy link
Collaborator

@pattivacek pattivacek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems pretty cool.

target_include_directories(aktualizr_static_lib PUBLIC
$<TARGET_PROPERTY:package_manager,INCLUDE_DIRECTORIES>)
target_include_directories(aktualizr_static_lib PUBLIC $<TARGET_PROPERTY:package_manager,INCLUDE_DIRECTORIES>)
target_include_directories(aktualizr_lib PUBLIC $<TARGET_PROPERTY:package_manager,INCLUDE_DIRECTORIES>)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these special bits for package_manager required?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To have access to ostree.h. I can double check that but it seems necessary.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, actually it doesn't look like it's making a difference... Removed in the last version.

${OPENSSL_LIBRARIES}
${sodium_LIBRARY_RELEASE}
${GLIB2_LIBRARIES})

if (BUILD_SOTA_TOOLS)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The endif and if here are redundant now.

CMakeLists.txt Outdated
@@ -213,6 +213,9 @@ if (CMAKE_CXX_COMPILER_ID MATCHES "(GNU|Clang)")
endif ()
endif()

# helpful for debugging installed executables, see `man ld-linux.so`
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really want this? I've had bad experiences with rpaths.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be for comfort only, I'll try without.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Specifically, this is the difference:

With:

$ DESTDIR=/tmp/test ninja install
$ /tmp/test/usr/local/bin/aktualizr --version
# works

without:

$ DESTDIR=/tmp/test ninja install
$ /tmp/test/usr/local/bin/aktualizr --version
# does not work
$ LD_LIBRARY_PATH=/tmp/test/usr/local/bin /tmp/test/usr/local/bin/aktualizr --version
# works

But then, it might be bad practice and cause other issues. Do you remember some details about the issues you had?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with using rpath is that you're forcing your path structure on your users. It means that when dynamically linking, everything in "$ORIGIN/../lib" will be taken over anything in the user's $LD_LIBRARY_PATH, which can have unintended side effects.

There are two points of view on this depending on what you think one's users prefer. One is that rpath makes it easier to find your library, but the downside is messing around with link path searching. The other is that rpath breaks traditional Linux norms and you should only really install things into default locations or change your PATH and/or LD_LIBRARY_PATH accordingly.

My preference is the latter, but I'm not set on that. Our circumstances are quite different than my past experience. If this makes things easier, it's fine. It does seem it'd make testing locally a bit easier.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My view is that if a user installs it to a non-standard path, it is up to them to adjust LD_LIBRARY_PATH accordingly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem with using rpath is that you're forcing your path structure on your users. It means that when dynamically linking, everything in "$ORIGIN/../lib" will be taken over anything in the user's $LD_LIBRARY_PATH, which can have unintended side effects.

According to the ld-linux.so's manual page, and a quick test, this doesn't seem to be the case. What CMake calls RPATH is actually RUNPATH which has a lower priority than LD_LIBRARY_PATH:

readelf -a usr/local/bin/aktualizr | grep PATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib]

That said, the risks of confusion might indeed outweigh the benefits, so I've removed it for now.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What CMake calls RPATH is actually RUNPATH

Wow, that is actually the most confusing part of all of this! If it's actually just setting RUNPATH, I don't really mind it. For now, though, if you've already removed it, let's see how it goes without it, and we can add it later if we think it'd be helpful.

test_aktualizr_secondary_uptane_verification uses ostree

Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
Identical functionality can directly be achieved through CMake

Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>
@codecov-io
Copy link

codecov-io commented Jan 9, 2020

Codecov Report

Merging #1512 into master will increase coverage by 0.02%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1512      +/-   ##
==========================================
+ Coverage    80.7%   80.72%   +0.02%     
==========================================
  Files         184      184              
  Lines       11156    11156              
==========================================
+ Hits         9003     9006       +3     
+ Misses       2153     2150       -3
Impacted Files Coverage Δ
src/libaktualizr/primary/sotauptaneclient.cc 88.71% <0%> (-0.15%) ⬇️
src/libaktualizr/storage/sqlstorage.cc 76.56% <0%> (ø) ⬆️
src/libaktualizr/isotp_conn/isotp_conn.cc 0.97% <0%> (+0.97%) ⬆️
src/libaktualizr/uptane/isotpsecondary.cc 1.33% <0%> (+1.33%) ⬆️
src/libaktualizr/package_manager/ostreereposync.cc 1.35% <0%> (+1.35%) ⬆️
src/libaktualizr/storage/sql_utils.h 86.11% <0%> (+1.38%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff077a7...fce010b. Read the comment docs.

endif (BUILD_SOTA_TOOLS)

# do not link tests with libaktualizr
list(REMOVE_ITEM TEST_LIBS aktualizr_lib)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought that the garage tools used some of functionality from libaktualizr, like Utils and such. Is that linked in still somehow, or how does that work now?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's now included in sota_tools_lib which links statically with libaktualizr. I've pushed some new changes to make it clearer.

* fix linking issues with secondary tests

These are difficult to link as they use parts of the primary and
secondary libs which don't play well with each others.

* link sota_tools_lib with aktualizr_static_lib to make it
self-contained

Signed-off-by: Laurent Bonnans <laurent.bonnans@here.com>

fixup! Fix linking issues with secondary tests
@lbonn lbonn merged commit bc54d32 into master Jan 9, 2020
@lbonn lbonn deleted the feat/dyn-library branch January 9, 2020 12:36
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants