pkg-config file Libs.private needs fixing about libde265 HOT 10 OPEN

I don't see anything in the CMakeLists.txt that ever wrote libpthread or libm to Libs.private. Can you point me to a version that wrote those entries?

Does that change improve it for you:

if(HAVE_LIBCPP)
  string(APPEND LIBS_PRIVATE "-lc++")
else()
  string(APPEND LIBS_PRIVATE "-lstdc++")
endif()

from libde265.

I am using autoconf.

autoconf uses LIBS internally.

AC_SEARCH_LIBS([pow], [m])
AC_SEARCH_LIBS([sqrt], [m])
AC_SEARCH_LIBS([pthread_create], [pthread])

Libs.private: used to list @LIBS@

The old value is proper and that's what it should be for static linking.

from libde265.

What holds you back from using cmake?

Those libraries are also missing in the cmake output, but I would prefer to fix the CMakeLists instead of keeping autoconf alive.

from libde265.

What holds you back from using cmake?

Those libraries are also missing in the cmake output, but I would prefer to fix the CMakeLists instead of keeping autoconf alive.

Yes, I also noticed it because of me playing with CMake. I would be fine with focusing on CMake.

Fixing sherlock265 and this issue and I think that's about it. I have a local patch to fix the pkg-config file but doing things upstream would be proper.

from libde265.

What actually requires these pthreads and libm in this field? I observed (on Linux) that libde265 is linked without referring to libpthreads or libm.
In libheif, we also use pthreads and it is also not in the Libs.private field and not linked explicitly.
What toolchain does need that?

from libde265.

Does this work for you? For me, it doesn't make a difference, because it is not linking explicitly to pthreads.

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6066e9ff..fd0e5421 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -52,6 +52,10 @@ else()
   set(LIBS_PRIVATE "-lstdc++")
 endif()
 
+if (NOT ("${CMAKE_THREAD_LIBS_INIT}" STREQUAL ""))
+  string(APPEND LIBS_PRIVATE " -l${CMAKE_THREAD_LIBS_INIT}")
+endif()
+
 option(BUILD_SHARED_LIBS "Build shared library" ON)
 if(NOT BUILD_SHARED_LIBS)
   add_definitions(-DLIBDE265_STATIC_BUILD)

from libde265.

What actually requires these pthreads and libm in this field? I observed (on Linux) that libde265 is linked without referring to libpthreads or libm. In libheif, we also use pthreads and it is also not in the Libs.private field and not linked explicitly. What toolchain does need that?

Relatively recent versions of glibc (https://developers.redhat.com/articles/2021/12/17/why-glibc-234-removed-libpthread#) have merged libpthread and libm into libc and contain stubs for backwards compatibility.

Libs.private: has a number of uses, but it's important for static linking.

non-Linux POSIX OS's. I am using OpenBSD but this applies for older glibc and other Linux libc implementations.

from libde265.

The generated pkg-config file looks like..

Libs.private: -lc++ -l-lpthread

from libde265.

Also I noticed the Libs: field..

Libs: -lde265 -L${libdir}

Usually the path comes first and then the library.

from libde265.

Ping.

from libde265.