- Nov 17, 2022
-
-
Simon McVittie authored
This does a few closely related things. If standard input, standard output and standard error are closed, we open them to point to /dev/null, and if they are close-on-exec, we clear their close-on-exec flags. This is to avoid weird side effects: most APIs like open() that create new file descriptors guarantee to use the lowest-numbered fd that is not already in use, but users of those APIs do not expect to be overwriting stdin/stdout/stderr. Because that operation can involve changing the meaning of stdout and stderr, we now optionally save a duplicate of the original standard output and standard error, so they can be put back later. Because we're now saving a duplicate of the original standard output and standard error, it also makes sense to implement SRT_LOG_FLAGS_DIVERT_STDOUT here. This avoids needing to call _srt_divert_stdout_to_stderr() separately in most callers. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we are going to write to the systemd Journal, we will want the program name to already be known, so that we can use it as the syslog identifier (first argument to sd_journal_stream_fd() and openlog()). This also reduces duplication a bit, and brings us one step closer to combining _srt_util_set_up_logging() with _srt_util_set_glib_log_handler(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 03, 2022
-
-
Simon McVittie authored
We can use this to set up different types of logging with a single log handler, which will make it easier to add new flags, such as a flag to make the log more deterministic to minimize diff. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 20, 2022
-
-
Simon McVittie authored
If we have setup.sh do the setup unconditionally and leave the decision of whether to activate or deactivate the shim to run.sh (by adding or not adding the libcurl_compat_32, libcurl_compat_64 directories in the search path), then it becomes easier to swap between the two arrangements. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2022
-
-
Simon McVittie authored
To test this mechanism, it's useful to have a set of libraries that implement a predictable interface between distributions. Use a small subset of the real libcurl API. Helps: steamrt/tasks#119 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This works around ABI divergence from upstream in the libcurl in Debian/Ubuntu between about 2005 and 2018, which unfortunately includes the time at which Steam Runtime 1 'scout' started. Modern versions of libcurl have versioned symbols attached to a verdef CURL_OPENSSL_4, but Debian introduced versioned symbols before upstream did, and used CURL_OPENSSL_3. We want to be compatible with both. Similarly, modern upstream versions of libcurl when built against GNUTLS have versioned symbols attached to a verdef CURL_GNUTLS_4, but Debian introduced versioned symbols attached to a verdef CURL_GNUTLS_3, and is still using that verdef as of 2022. We want to be compatible with both, if we can. The trick here is that since glibc 2.30, the dynamic linker does not require triples (SONAME, version, symbol), but only looks for pairs of (SONAME, version) and, independently, (version, symbol). This means that dependencies on versioned symbols can be satisfied by any of the recursive dependencies of the library found when searching for the SONAME, and not just the library itself. glibc seems to have introduced this functionality so that glibc itself would be able to move symbols from its smaller libraries into libc.so.6 without breaking compatibility. The shim library has verdefs for both sets of versioned symbols, so it can be positioned in the search path as libcurl.so.4 and will satisfy both sets of requirements for the verdefs. For the actual symbols, it delegates to libsteam-runtime-system-libcurl.so.4 and libsteam-runtime-our-libcurl.so.4, which are expected to be set up by the runtime's setup.sh as symlinks to the real libraries that implement the two faces of libcurl. This requires some setup, which will be coordinated by a new version of setup.sh, in each of the pinned_libs_* directories. The real work is done by libcurl-compat/compat-setup.c, which uses the steam-runtime-tools library to find out whether the system libcurl is compatible with the expected ABIs. If there is no system copy of libcurl, then we do not need to do all this and can use the runtime's libcurl directly: binaries that rely on having a newer libcurl will fail, but by definition those binaries can't have been built or tested against the scout runtime. Helps: steamrt/tasks#119 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-