[ Question ] Is librt linkage really necessary?

[avafinger]

I've been trying to create a deb package for Debian 10 (not sure if there is a deb package for Debian 11 and/or Ubuntu 22.04 LTS) but i get the following message:

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/libsdl3/usr/lib/aarch64-linux-gnu/libSDL3.so.0.0.0 was not linked against librt.so.1 (it uses none of the library's symbols)

Checking the installation from cmake:

rock@rock5b:~/rockchip/sdl$ ldd /usr/local/lib/libSDL3.so.0.0.0 linux-vdso.so.1 (0x0000007f9d45f000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f9d0ec000) libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f9d0d8000) librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f9d0c0000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f9d091000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f9cf20000) /lib/ld-linux-aarch64.so.1 (0x0000007f9d431000)

And from my attempt to create deb package:

rock@rock5b:~/rockchip/sdl/libsdl3-3.0.0$ ldd ./debian/tmp/usr/lib/aarch64-linux-gnu/libSDL3.so linux-vdso.so.1 (0x0000007f91ca5000) libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f91a10000) libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f919fc000) librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000007f919e4000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f919b5000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f91844000) /lib/ld-linux-aarch64.so.1 (0x0000007f91c77000)

I think librt gets the linked instruction by:

    # HIDAPI/libusb libs
    AC_CHECK_LIB([rt], [clock_gettime], [LIBS_LIBUSB_PRIVATE+=" -lrt"], [hidapi_lib_error librt])
    PKG_CHECK_MODULES([libusb], [libusb-1.0 >= 1.0.9], true, [hidapi_lib_error libusb-1.0])
    LIBS_LIBUSB_PRIVATE+=" $libusb_LIBS"
    CFLAGS_LIBUSB+=" $libusb_CFLAGS"

Checking librt symbols on arm64

rock@rock5b:~/rockchip/sdl$ nm /usr/lib/aarch64-linux-gnu/librt.a | grep ' T ' | grep -v ' __'
nm: aio_read64.o: no symbols
nm: aio_write64.o: no symbols
nm: lio_listio64.o: no symbols
nm: clock-compat.o: no symbols
0000000000000000 T aio_cancel
0000000000000000 T aio_error
0000000000000000 T aio_fsync
0000000000000000 T aio_read
0000000000000000 T aio_return
0000000000000120 T aio_suspend
0000000000000000 T aio_write
0000000000000000 T timer_create
0000000000000000 T timer_delete
0000000000000000 T timer_getoverrun
0000000000000000 T timer_gettime
0000000000000000 T timer_settime
0000000000000000 T shm_open
0000000000000000 T shm_unlink
0000000000000000 T mq_open
0000000000000000 T mq_close
0000000000000000 T mq_unlink
0000000000000000 T mq_getattr
0000000000000000 T mq_setattr
00000000000002f8 T mq_notify
0000000000000000 T mq_send
0000000000000000 T mq_receive

I have libusb installed, but not linked against librt.

Update:

rock@rock5b:~/rockchip/sdl/libsdl3-3.0.0$ ldd /usr/lib/aarch64-linux-gnu/libusb-1.0.so.0.1.0 linux-vdso.so.1 (0x0000007fb052d000) libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007fb0491000) libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007fb0462000) libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007fb02f1000) /lib/ld-linux-aarch64.so.1 (0x0000007fb04ff000)

[sezero]

librt is usually needed for clock_gettime

[avafinger]

I think you mean POSIX.

I made the following experiment:

Compiled and linked the attached gt.c.zip

gcc -o gt gt.c

rock@rock5b:~/rockchip/sdl$ nm ./gt
0000000000011058 b a.4994
                 U abort@@GLIBC_2.17
0000000000011080 B __bss_end__
0000000000011080 B _bss_end__
0000000000011050 B __bss_start
0000000000011050 B __bss_start__
0000000000000778 t call_weak_fn
                 U clock_gettime@@GLIBC_2.17
0000000000011050 b completed.8216
                 w __cxa_finalize@@GLIBC_2.17
0000000000011040 D __data_start
0000000000011040 W data_start
0000000000000790 t deregister_tm_clones
00000000000007f8 t __do_global_dtors_aux
0000000000010dc0 t __do_global_dtors_aux_fini_array_entry
0000000000011048 D __dso_handle
0000000000010dc8 a _DYNAMIC
0000000000011050 D _edata
0000000000011080 B __end__
0000000000011080 B _end
                 U exit@@GLIBC_2.17
00000000000009bc T _fini
0000000000000840 t frame_dummy
0000000000010db8 t __frame_dummy_init_array_entry
0000000000000b70 r __FRAME_END__
0000000000010fa8 a _GLOBAL_OFFSET_TABLE_
                 w __gmon_start__
0000000000000a30 r __GNU_EH_FRAME_HDR
0000000000000680 t _init
0000000000010dc0 t __init_array_end
0000000000010db8 t __init_array_start
00000000000009d0 R _IO_stdin_used
                 w _ITM_deregisterTMCloneTable
                 w _ITM_registerTMCloneTable
00000000000009b8 T __libc_csu_fini
0000000000000938 T __libc_csu_init
                 U __libc_start_main@@GLIBC_2.17
0000000000000844 T localpid
0000000000000854 T main
                 U printf@@GLIBC_2.17
00000000000007c0 t register_tm_clones
                 U sleep@@GLIBC_2.17
0000000000000740 T _start
0000000000011050 D __TMC_END__

Maybe some other library that was not linked in my current setup? (debian 10)

gt.c.zip

[sezero]

Depending on libc version, clock_gettime may reside in libc itself or may need additional linkage to librt. On my old setup with glibc-2.12 for example, I do need linking to librt for it.

[madebr]

We do something similar for dlopen. Some distros/versions of libc don't require an explicit link to libdl/librt: mine (=Fedora) also doesn't.

[madebr]

For glibc >=2.17, librt is a stub-only library.

* The `clock_*' suite of functions (declared in <time.h>) is now available
  directly in the main C library.  Previously it was necessary to link with
  -lrt to use these functions.  This change has the effect that a
  single-threaded program that uses a function such as `clock_gettime' (and
  is not linked with -lrt) will no longer implicitly load the pthreads
  library at runtime and so will not suffer the overheads associated with
  multi-thread support in other code such as the C++ runtime library.

[avafinger]

right.

Debian 10 was released on 2019-07-06. What's the drawback to keeping librt linked with the latest glibc? If it is harmless i guess nothing to worry here then?

[avafinger]

If anyone would like to comment on the librt, please do so. Will keep it for backward compatibility with older versions. Anyway, the final deb package needs to be stripped from debugging info. Need to find a way to do this, until then it's for learning purposes only.

[avafinger]

I would like to mention that the final library is now stripped from debugging info. It is not a first-class programming style but if someone wants to enhance it, please fill free.

It works on arm64 X11 and KMSDRM/GBM.

lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy

sdl3-config --libs
-Wl,-rpath,/usr/lib/aarch64-linux-gnu -Wl,--enable-new-dtags -lSDL3

sudo ./yuvtest ~/videos/jellyfish-10-mbps-hd-hevc-10bit.mkv 
INFO: Video Framerate: 29.97
INFO: libSDL: compiled with=3.0.0 linked against=3.0.0
INFO: Renderer Driver (default): (null)
INFO: Renderer Driver (set): opengles2
error: XDG_RUNTIME_DIR not set in the environment.
arm_release_ver of this libmali is 'g6p0-01eac0', rk_so_ver is '5'.
INFO: Platform: Linux      Cores=8   CacheL1=128 kb   System RAM=3737 MB
INFO: Window:   0x55ab3f55d0  1920x1080@32bpp SDL_PIXELFORMAT_ARGB8888 Rmask=0xff0000 Gmask=0xff00 Bmask=0xff Amask=0xff000000
INFO: Renderer: 0x55ab49a700  opengles2 SW=NO HWACCEL=YES VSYNC=YES TARGETTEXTURE=YES MaxTexure=16383x16383
INFO: Renderer: 0x55ab49a700  9 Available Textures
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_ARGB8888
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_ABGR8888
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_RGB888
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_BGR888
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_YV12
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_IYUV
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_NV12
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_NV21
INFO: Renderer: 0x55ab49a700    SDL_PIXELFORMAT_EXTERNAL_OES
INFO: Texture:   0x55abb31040  1920x1080@86bpp SDL_PIXELFORMAT_YV12 Access=SDL_TEXTUREACCESS_STATIC
INFO: SDL3 init with success!.
INFO: Rendering non-contiguous (may be padded) YUV
[hevc_rkmpp @ 0x55ab27ff30] Decoder noticed an info change (1920x1080), format=1
INFO: Exiting...
INFO: Done!.

mkdir -p rockchip/sdl cd rockchip/sdl git clone -b sdl3-rockchip-deb-package-arm64-tested https://github.com/avafinger/SDL --depth=1 cd SDL sudo dpkg-buildpackage -b -uc -us

I tested it on Intel x64 (amd64), and it works.

Distributor ID: Ubuntu Description: Ubuntu 18.04.6 LTS Release: 18.04 Codename: bionic

sdl3-config --libs
-Wl,-rpath,/usr/lib/x86_64-linux-gnu -Wl,--enable-new-dtags -lSDL

ii  libsdl3                                    3.0.0-1                                         amd64        Simple DirectMedia 3 library
ii  libsdl3-dev                                3.0.0-1                                         amd64        Simple DirectMedia 3 dev-headers

./yuvtest /home/alex/Downloads/1610170204_looped_1610170203.mp4 
INFO: Video Framerate: 25.00
INFO: libSDL: compiled with=3.0.0 linked against=3.0.0
INFO: Renderer Driver (default): (null)
INFO: Renderer Driver (set): opengles2
INFO: Platform: Linux      Cores=2   CacheL1=64 kb   System RAM=3935 MB
INFO: Window:   0x55e982b2dad0  384x480@32bpp SDL_PIXELFORMAT_RGB888 Rmask=0xff0000 Gmask=0xff00 Bmask=0xff Amask=0x0
INFO: Renderer: 0x55e982b357a0  opengles2 SW=NO HWACCEL=YES VSYNC=YES TARGETTEXTURE=YES MaxTexure=8192x8192
INFO: Renderer: 0x55e982b357a0  9 Available Textures
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_ARGB8888
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_ABGR8888
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_RGB888
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_BGR888
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_YV12
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_IYUV
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_NV12
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_NV21
INFO: Renderer: 0x55e982b357a0    SDL_PIXELFORMAT_EXTERNAL_OES
INFO: Texture:   0x55e982e225b0  384x480@86bpp SDL_PIXELFORMAT_YV12 Access=SDL_TEXTUREACCESS_STATIC
INFO: SDL3 init with success!.
INFO: Rendering non-contiguous (may be padded) YUV
INFO: Exiting...
INFO: Done!.