obs-studio

obs-studio copied to clipboard

Operating System Info

Other

Other OS

Debian

OBS Studio Version

29.1.3

OBS Studio Version (Other)

No response

OBS Studio Log URL

n.n.

OBS Studio Crash Log URL

n.n.

Expected Behavior

obs explicitly encodes all runtime dependencies to dynamic libraries.

Current Behavior

building obs results in a libobs.so which uses symbols from libm but fails to link against the library.

Steps to Reproduce

$ wget https://github.com/obsproject/obs-studio/releases/download/29.1.3/obs-studio_29.1.3-0obsproject1.focal_amd64.deb
$ dpkg -x obs-studio_29.1.3-0obsproject1.focal_amd64.deb OBS
$ strings OBS/usr/lib/x86_64-linux-gnu/libobs.so.29 | grep asinf
asinf
$ readelf -d OBS/usr/lib/x86_64-linux-gnu/libobs.so.29  | grep  lib
 0x0000000000000001 (NEEDED)             Shared library: [libavcodec.so.58]
 0x0000000000000001 (NEEDED)             Shared library: [libavformat.so.58]
 0x0000000000000001 (NEEDED)             Shared library: [libavutil.so.56]
 0x0000000000000001 (NEEDED)             Shared library: [libswscale.so.5]
 0x0000000000000001 (NEEDED)             Shared library: [libswresample.so.3]
 0x0000000000000001 (NEEDED)             Shared library: [libjansson.so.4]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libX11-xcb.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libxcb.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libuuid.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpulse.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libgio-2.0.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libwayland-client.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libxkbcommon.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libX11.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]
 0x000000000000000e (SONAME)             Library soname: [libobs.so.0]
 0x000000000000001d (RUNPATH)            Library runpath: [/usr/lib/x86_64-linux-gnu]
$ readelf -d OBS/usr/lib/x86_64-linux-gnu/libobs.so.29  | grep  libm
$

Anything else we should know?

typically this is not a very big deal, as libm is pulled in via various other libraries.

nevertheless i think that any direct dependency should be expressed explicitly (rather than implicitly trusting that somebody else will do the work)

I wonder how this could actually happen - if <math.h> is required, then compilation should fail if it cannot be resolved by the linker.

In same cases libm is indeed part of libc so explicit linking isn't required, but that's something the Linux maintainers have to figure out.

Aside, does this actually have any real-world implications that you are observing? If not, we are happy to receive and review any PRs but aren't too concerned about this as-is.

I wonder how this could actually happen - if <math.h> is required, then compilation should fail if it cannot be resolved by the linker.

as i said: many dependencies (dynamic libraries) of obs-studio themselves pull in libm. (and because of the way the linux dynamic linker works, these secondary dependencies can satisfy the primary requirement of the calling application; so to answer @gxalpha 's remark: no, i haven't seen any real-world implications)

nevertheless: if obs-studio uses symbols from <math.h> and these symbols are provided by libm, then obs-studio should link against libm (even if it just "happens to work")

nevertheless: if obs-studio uses symbols from <math.h> and these symbols are provided by libm, then obs-studio should link against libm (even if it just "happens to work")

So the point being is that libobs by itself supposedly does depend on libm, but that dependency is accidentally resolved by one of the many compile-time dependencies the linker pulls in already?

exactly

Feel free to open a PR for that - if you're unsure about the platforms that might require this, an CMake snippet can be used to determine this given the current compiler environment:

include(CheckCSourceCompiles)
set(LIBM_TEST_SOURCE "#include<math.h>\nfloat f; int main(){sqrt(f);return
0;}")
check_c_source_compiles("${LIBM_TEST_SOURCE}" HAVE_MATH_IN_STD_LIB)

Given that we officially support only 3 platforms with some support for FreeBSD thrown into the mix that might be a bit overkill (and can generally be guarded by our OS detection), but I leave that up to whoever opens that PR.

For reference: on FreeBSD there should be a libm dependency (that is, we don't have the math fns in libc). I agree that in practice libm is likely always pulled in anyway.