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

Ignore ldconfig failures when installing on Linux #346

Open
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
2 participants
@ilammy
Collaborator

ilammy commented Dec 6, 2018

Currently make install PREFIX=$HOME/lib/themis fails on Linux when run without superuser privileges. Installation to non-system directories should not require superuser privileges. This does not work because of an unconditional ldconfig invocation.

Linux systems generally require an ldconfig invocation after installing shared libraries in order to refresh ld.so's library cache. Themis' make install target does that unconditionally when building on Linux. It's not necessary for static libraries or when installing into non-system locations that require special configuration of the dynamic loader (rpath, LD_LIBRATY_PATH, etc.)

Note that ldconfig requires superuser privileges as it writes multiple files in /etc. However, make install is not always run with superuser privileges.

There are two basic use-cases for installing Themis:

  • Installation into the system directory

    Typically this is used when packaging Themis library by itself. This installation requires superuser privileges anyway to copy the libraries into system locations. Usually shared libraries are installed together with static libraries.

    This is typically invoked as sudo make install

  • Installation into a temporary directory

    Typically this is used to build a local copy of Themis for use inside another project. Themis is installed into some non-system location by setting the PREFIX variable accordingly. Usually only static libraries are used. No superuser privileges needed.

    This is typically invoked as make install PREFIX=$somewhere

The first use-case works fine now, but the second one is broken by ldconfig failing the build without superuser privileges.

Let's fix it in a simple and lazy way by ignoring any errors caused by ldconfig. (They are still printed out to stderr though.)

Strictly speaking, we should invoke ldconfig only after installing shared libraries. And it's only needed when installing into system locations. However, it's too complex for us to analyze EUID and PREFIX values. And it's certainly easier for the users to simply run "make install" all the time. Though, it's definitely possible to add a new target which will not call ldconfig:

install_static: install_soter_headers install_themis_headers \
                install_static_libs install_pkgconfig

install: install_static install_shared_libs
ifdef IS_LINUX
        @ldconfig
endif

However, there may be cases when shared libraries need to be installed into non-system locations as well. So it should be more easy to simply ignore ldconfig failures.

Ignore ldconfig failures when installing on Linux
Currently `make install PREFIX=$HOME/lib/themis` fails on Linux
when run without superuser privileges. Installation to non-system
directories should not require superuser privileges. This does not
work because of an unconditional `ldconfig` invocation.

Linux systems generally require an `ldconfig` invocation after
installing shared libraries in order to refresh ld.so's library
cache. Themis' "make install" target does that unconditionally
when building on Linux. It's not necessary for static libraries
or when installing into non-system locations that require special
configuration of the dynamic loader (rpath, LD_LIBRATY_PATH, etc.)

Note that `ldconfig` requires superuser privileges as it writes
multiple files in /etc. However, "make install" is not always run
with superuser privileges.

There are two basic use-cases for installing Themis:

- Installation into the system directory

  Typically this is used when packaging Themis library by itself.
  This installation requires superuser privileges anyway to copy
  the libraries into system locations. Usually shared libraries
  are installed together with static libraries.

  This is typically invoked as `sudo make install`

- Installation into a temporary directory

  Typically this is used to build a local copy of Themis for use
  inside another project. Themis is installed into some non-system
  location by setting the PREFIX variable accordingly. Usually
  only static libraries are used. No superuser privileges needed.

  This is typically invoked as `make install PREFIX=$somewhere`

The first use-case works fine now, but the second one is broken
by `ldconfig` failing the build without superuser privileges.

Let's fix it in a simple and lazy way by ignoring any errors caused
by `ldconfig`. (They are still printed out to stderr though.)

Strictly speaking, we should invoke `ldconfig` only after installing
shared libraries. And it's only needed when installing into system
locations. However, it's too complex for us to analyze EUID and
PREFIX values. And it's certainly easier for the users to simply
run "make install" all the time. Though, it's definitely possible
to add a new target which will not call `ldconfig`:

    install_static: install_soter_headers install_themis_headers \
                    install_static_libs install_pkgconfig

    install: install_static install_shared_libs
    ifdef IS_LINUX
            @ldconfig
    endif

However, there may be cases when shared libraries need to be
installed into non-system locations as well. So it should be more
easy to simply ignore `ldconfig` failures.

@ilammy ilammy added the installation label Dec 6, 2018

@ilammy ilammy requested review from vixentael and shadinua Dec 6, 2018

@shadinua

Taking into account that the global file refactoring is planned, I think we can use this as a temporary solution.

But I'd propose to ignore ldconfig errors only when effective user (based on $USER environment variable) is not root.
I think this will be in accordance with the problem described in the PR.

Thank you!

Ignore ldconfig failures only for non-root users
Actually, do check that we are running as root by looking at our EUID.
If we're a non-root user then ignore ldconfig failures. Otherwise exit
with the status code returned by ldconfig and propagate the error.
@ilammy

This comment has been minimized.

Collaborator

ilammy commented Dec 6, 2018

@shadinua that makes sense.

I have added the check so that ldconfig will faithfully fail if the build is run by a superuser. Errors will be ignored only for non-root users.

I have used bit more resilient way of checking the effective UID ($(id -u) = "0"), just in case the root user is not named root.

@shadinua

Great, thanks!

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