Library not linked against libdl for multilib build on Linux
Issue #202
resolved
When using the script build/linux/multilib.sh to build a multilib version of x265, the resulting shared library uses symbols from libdl but isn't linked against it. This caused some problems when I tried to configure ffmpeg with libx265 enabled.
Afaik BSD-like systems don't have a separate libdl file so I guess this is a Linux-specific issue.
I recommend something like the following changes:
--- multilib.sh.orig 2015-10-17 16:22:20.088480771 +0200
+++ multilib.sh 2015-10-17 16:22:10.840480613 +0200
@@ -10,16 +10,21 @@
cmake ../../../source -DHIGH_BIT_DEPTH=ON -DEXPORT_C_API=OFF -DENABLE_SHARED=OFF -DENABLE_CLI=OFF
make ${MAKEFLAGS}
+uname=`uname`
+
cd ../8bit
ln -sf ../10bit/libx265.a libx265_main10.a
ln -sf ../12bit/libx265.a libx265_main12.a
-cmake ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
+if [ "$uname" = "Linux" ]; then
+ # On Linux, we need to link against libdl
+ libdl=";-ldl"
+fi
+cmake ../../../source -DEXTRA_LIB="x265_main10.a;x265_main12.a$libdl" -DEXTRA_LINK_FLAGS=-L. -DLINKED_10BIT=ON -DLINKED_12BIT=ON
make ${MAKEFLAGS}
# rename the 8bit library, then combine all three into libx265.a
mv libx265.a libx265_main.a
-uname=`uname`
if [ "$uname" = "Linux" ]
then
Comments (2)
-
-
- changed status to resolved
cmake: correct order of linking, fixes
#202First, the library which needs symbols. Next, the library which resolves symbols.
→ <<cset b6d0c1ce70f5>>
- Log in to comment
The shared objects are already linked with -ldl, but it's at the wrong place. The order of objects matters when linking. The following patch also fixes the issue:
It would also be nice if the code using dlopen wouldn't be built for the multilib build as it will never be used.