-
Notifications
You must be signed in to change notification settings - Fork 61
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems pretty cool.
src/libaktualizr/CMakeLists.txt
Outdated
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>) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
src/sota_tools/CMakeLists.txt
Outdated
${OPENSSL_LIBRARIES} | ||
${sodium_LIBRARY_RELEASE} | ||
${GLIB2_LIBRARIES}) | ||
|
||
if (BUILD_SOTA_TOOLS) |
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 actuallyRUNPATH
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 <[email protected]>
Identical functionality can directly be achieved through CMake Signed-off-by: Laurent Bonnans <[email protected]>
Signed-off-by: Laurent Bonnans <[email protected]>
f78aebd
to
c8379e3
Compare
Codecov Report
@@ 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
Continue to review full report at Codecov.
|
src/sota_tools/CMakeLists.txt
Outdated
endif (BUILD_SOTA_TOOLS) | ||
|
||
# do not link tests with libaktualizr | ||
list(REMOVE_ITEM TEST_LIBS aktualizr_lib) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 <[email protected]> fixup! Fix linking issues with secondary tests
c8379e3
to
fce010b
Compare
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.