[PATCH] libdvdread: `dvdread-config --libs` should include "-ldl"
libdvdread's shared library uses libdl functions. However, the output of `dvdread-config --libs` does not include "-ldl". An application using dvdread-config but does not use libdl itself will therefore fail to link against libdvdread. Patch adds "-ldl" to the appropriate output strings in dvdread-config.sh and dvdread-config.in -- Yang Zhao
On Wednesday 29 October 2008 08:09:23 Yang Zhao wrote:
libdvdread's shared library uses libdl functions. However, the output of `dvdread-config --libs` does not include "-ldl". An application using dvdread-config but does not use libdl itself will therefore fail to link against libdvdread.
Patch adds "-ldl" to the appropriate output strings in dvdread-config.sh and dvdread-config.in
please, someone commit it. Thanks for the patch
Hi,
libdvdread's shared library uses libdl functions. However, the output of `dvdread-config --libs` does not include "-ldl". An application using dvdread-config but does not use libdl itself will therefore fail to link against libdvdread.
Patch adds "-ldl" to the appropriate output strings in dvdread-config.sh and dvdread-config.in
Hmm wait. Shouldn't that be outputted only when linking statically ? libdvdread.so should be linked to libdl if needed, what's the problem with not having -ldl in --libs ? By the way, as far as I know, libdl isn't a standard thing, see eg. [1], freebsd does not have libdl and this patch will probably cause any application using dvdread-config to fail on freebsd... Regards, Alexis. [1] http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?dlopen
2008/10/29 Alexis Ballier <aballier@gentoo.org>:
Patch adds "-ldl" to the appropriate output strings in dvdread-config.sh and dvdread-config.in
Hmm wait. Shouldn't that be outputted only when linking statically ? libdvdread.so should be linked to libdl if needed, what's the problem with not having -ldl in --libs ?
I'm currently trying to test compatibility of Gentoo's various libdvdread-dependent packages with libdvdread-4.1.3. vobcopy is first on my list, and this is where I'm hitting the problem. Putting aside the fact that vobcopy's build system isn't exactly pretty, linking by hand results in the following: yzhao@awa ~/hacking/vobcopy-1.1.2 $ gcc -o vobcopy vobcopy.o dvd.o -ldvdread /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlsym' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlopen' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlclose' collect2: ld returned 1 exit status
By the way, as far as I know, libdl isn't a standard thing, see eg. [1], freebsd does not have libdl and this patch will probably cause any application using dvdread-config to fail on freebsd...
Good point; I wasn't aware of that. Looking at the code in more detail, ld* functionality is used when HAVE_DVDCSS_DVDCSS_H is undefined when compiling under certain platforms. However, neither configure.ac nor configure2 seems to actually do the checks and set this; libdvdcss is installed on my machine. The correct solution, then seems to be updating configure to take libdvdcss into account, and generate dvdread-config accordingly. Relatedly, is configure2 still the preferred way, or is it already considered unmaintained? -- Yang Zhao
Hi,
2008/10/29 Alexis Ballier <aballier@gentoo.org>:
Patch adds "-ldl" to the appropriate output strings in dvdread-config.sh and dvdread-config.in
Hmm wait. Shouldn't that be outputted only when linking statically ? libdvdread.so should be linked to libdl if needed, what's the problem with not having -ldl in --libs ?
I'm currently trying to test compatibility of Gentoo's various libdvdread-dependent packages with libdvdread-4.1.3.
The ebuild uses configure2 and allows user ldflags. Are you using as-needed by any chance ? If yes, please try the enclosed patch. With the current configure2 build system, if I link with as-needed, libdvdread.so gets its libdl linkage dropped.
yzhao@awa ~/hacking/vobcopy-1.1.2 $ gcc -o vobcopy vobcopy.o dvd.o -ldvdread /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlsym' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlopen' /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../libdvdread.so: undefined reference to `dlclose' collect2: ld returned 1 exit status
That just means libdvdread should be linked to libdl :)
The correct solution, then seems to be updating configure to take libdvdcss into account, and generate dvdread-config accordingly.
that would make any dvdread-config consumer wrongly link to libdl :(
Relatedly, is configure2 still the preferred way, or is it already considered unmaintained?
Good question; and by the way, configure2 always links to libdl while the autofoo seems to have better handling of dlopen stuff. Which means configure2 will probably fail on freebsd. Regards, Alexis.
2008/10/29 Alexis Ballier <aballier@gentoo.org>:
The ebuild uses configure2 and allows user ldflags. Are you using as-needed by any chance ?
Indeed I am.
If yes, please try the enclosed patch. With the current configure2 build system, if I link with as-needed, libdvdread.so gets its libdl linkage dropped.
Yup, that fixed it. Looks like my understanding of shared library linking is still a little off. :)
The correct solution, then seems to be updating configure to take libdvdcss into account, and generate dvdread-config accordingly.
So, the libdl issue was something else. Still, is the lack of libcss check an oversight or intentional to disable broken code?
Relatedly, is configure2 still the preferred way, or is it already considered unmaintained?
Good question; and by the way, configure2 always links to libdl while the autofoo seems to have better handling of dlopen stuff. Which means configure2 will probably fail on freebsd.
I've noticed this as well. Thanks, -- Yang Zhao
participants (3)
-
Alexis Ballier -
Nico Sabbi -
Yang Zhao