Open peterbillam opened 7 years ago
This seems to be a duplicate of #9 where it was found to be a bug in libao that was fixed in libao 1.2.0. https://trac.xiph.org/ticket/1841
We should wrap the l_file_extension
definition in a header version check.
We should wrap the l_file_extension definition in a header version check.
True. <C-naive apologies...> Er... #ifdef can only test macros, though, can't it? so we can't doifdef ao_file_extension
can we ? and I don't see a #define VERSION=1.1 in my /usr/include/ao/*.h files.
Or does it come in from the rockspec ?
Er... #ifdef can only test macros, though, can't it? so we can't do
ifdef ao_file_extension
can we ? and I don't see a #define VERSION=1.1 in my /usr/include/ao/*.h files.
Ouch. That's correct; it looks like libao haven't provided any version in headers. In cases like these is where you usually bring in the big guns like autoconf/meson/cmake for feature-testing. However I have a strong dislike for such systems....
We might be able to do something with weak symbols...
For now I think we just put it behind a define HAVE_AO_FILE_EXTENSION
and default to not-present.
However I have a strong dislike for such systems
Agreed. Sledgehammer to crack a nut.
For now I think we just put it behind a define
HAVE_AO_FILE_EXTENSION
and default to not-present.
Fine. I'll do it. Thanks for your help :-)
I've just installed a new debian, and I'm getting that
lua: error loading module 'ao' from file '/usr/local/lib/lua/5.3/ao.so':
/usr/local/lib/lua/5.3/ao.so: undefined symbol: ao_file_extension
error. This means that lots of people probably get it. Seeing that ao_file_extension only occurs in the l_file_extension routine, which is undocumented in lao and always has been, I'd like to suggest that we comment out that routine . . .