pkg-config file Libs.private needs fixing

[brad0]

After 510abe6 the package-config file field Libs.private: no longer properly lista the libpthread or libm libraries.

[farindk]

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()

[brad0]

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.

[farindk]

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.

[brad0]

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.

[farindk]

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?

[farindk]

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)

[brad0]

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.

[brad0]

The generated pkg-config file looks like..

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

[brad0]

Also I noticed the Libs: field..

Libs: -lde265 -L${libdir}

Usually the path comes first and then the library.

[brad0]

Ping.