New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow linking to libsystemd, libsystemd-daemon, libresolv, and libcap #102

Open
rinigus opened this Issue Feb 19, 2018 · 5 comments

Comments

Projects
None yet
2 participants
@rinigus
Contributor

rinigus commented Feb 19, 2018

To use systemd socket functionality, I need to link to systemd libraries, as specified by

    PKGCONFIG += libsystemd-daemon

Looks like its making SDK 1710 rpm validator rather unhappy:

ERROR [/usr/share/harbour-osmscout-server/lib/libsystemd-daemon.so.0] Cannot link to shared library: libresolv.so.2
ERROR [/usr/share/harbour-osmscout-server/lib/libsystemd-daemon.so.0] Cannot link to shared library: libcap.so.2
ERROR [/usr/bin/harbour-osmscout-server] Cannot link to shared library: libsystemd.so.0

ERROR [libcap.so.2] Cannot require shared library: 'libcap.so.2'
ERROR [libresolv.so.2] Cannot require shared library: 'libresolv.so.2'

While requires I can probably ignore, I expect that it will be harder to ignore validation errors for linking. I have included several libraries as "Private shared libs", including one from systemd, but maybe its a mistake and I shouldn't start shipping most of systemd as private share libs.

Hence, I would like to ask to allow these libraries to be linked to for the apps in Harbour.

@rinigus rinigus changed the title from Allow linking to libsystemd, libresolv, and libcap to Allow linking to libsystemd, libsystemd-daemon, libresolv, and libcap Feb 19, 2018

@pvuorela

This comment has been minimized.

Contributor

pvuorela commented Feb 21, 2018

First could point that libsystemd-daemon is deprecated and the functionality is nowadays in libsystemd.

libresolv.so.2 could perhaps be allowed, included in glibc so sounds safe to me.
libpcap maybe less useful, don't think private instances of systemd libs are good enough reason.

For libsystemd, why would you need that?

@rinigus

This comment has been minimized.

Contributor

rinigus commented Feb 21, 2018

For libsystemd, why would you need that?

I need it for providing socket activation by systemd. Namely, my OSM Scout Server allows users to activate systemd socket that will be listening locally on a dedicated port. When any of the map clients, such as Poor Maps, Poor Maps GL, modRana, will try to fetch the map, calculate the route or search for some address, systemd will fire up OSM Scout Server and, via systemd file descriptor, the server will respond to the connection without loosing any packages.

In practice, it works very well. OSM Scout Server works invisibly for the users providing offline maps stack on the devices. Only when you need to get new maps, its GUI is fired and operations performed. After that, users can just forget about it and use their favorite maps applications as if they are providing full service.

Due to such activation, OSM Scout Server is not running when its not needed. After activation by systemd, it is shutting itself down after some grace period of inactivity.

Since its all explained to the users as well via help screens, the application has been in Harbour for a while with this feature. Looks like some recent update has changed system-daemon library so that I get full stack of libsystemd and its dependencies. As you mentioned, libsystemd-daemon is deprecated and moved to libsystemd.

In particular, I need to access sd_listen_fds and SD_LISTEN_FDS_START which are defined in systemd sources (see https://github.com/rinigus/osmscout-server/blob/master/src/uhttp/microhttpserver.cpp#L164)

In essence, I am using Linux functionality to provide the best user experience and doing so with the user's permissions (no root needed).

@pvuorela

This comment has been minimized.

Contributor

pvuorela commented Feb 21, 2018

Thanks for the explanation. Background services for third party apps is one thing that hasn't gotten much focus. At the moment I'm cautious for blessing libsystemd, but should sooner or later solve the problem.

@rinigus

This comment has been minimized.

Contributor

rinigus commented Feb 21, 2018

OK, I will wait then till libsystemd is allowed in Harbour. For now, I should probably postpone any updates to Harbour of OSM Scout Server and distribute the new versions only via OpenRepos and OBS. I still think its too much to start adding libsystemd as a "private shared libs" to the application.

@pvuorela

This comment has been minimized.

Contributor

pvuorela commented Mar 23, 2018

For libresolv:
#106

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment