lirc @0.9.4c_1 build fails on older systems due to redefinition of scandir() in 10.8+

[kencu (Ken)]

On Snow Leopard, build fails when compiling

lirc-0.9.4c/tools/lirc-lsremotes.cpp

error is

/opt/local/bin/clang++-mp-3.8 -DHAVE_CONFIG_H -I. -I..  -I../lib -I..  -I/opt/local/include -DDARWIN -g -Wall -Wp,-D_FORTIFY_SOURCE=2 -I/opt/local/include  -pipe -Os -arch x86_64 -stdlib=libc++ -MT lirc-lsremotes.o -MD -MP -MF .deps/lirc-lsremotes.Tpo -c -o lirc-lsremotes.o lirc-lsremotes.cpp
lirc-lsremotes.cpp:213:9: error: no matching function for call to 'scandir'
        size = scandir(dirpath, &namelist, isfile, alphasort);
               ^~~~~~~
/usr/include/dirent.h:128:5: note: candidate function not viable: no known conversion from 'int (const struct dirent *)' to 'int (*)(struct dirent *)' for 3rd argument
int scandir(const char *, struct dirent ***,
    ^
lirc-lsremotes.cpp:237:9: error: no matching function for call to 'scandir'
        size = scandir(dirpath, &namelist, isdir, alphasort);
               ^~~~~~~
/usr/include/dirent.h:128:5: note: candidate function not viable: no known conversion from 'int (const struct dirent *)' to 'int (*)(struct dirent *)' for 3rd argument
int scandir(const char *, struct dirent ***,

Searching reveals similar issues with scandir have been noted in other projects <​https://github.com/Homebrew/legacy-homebrew/issues/13649>.

It appears the definition of scandir, located in /usr/include/dirent.h, changed in Mountain Lion from this

#if !defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE)
int scandir(const char *, struct dirent ***,
    int (*)(struct dirent *), int (*)(const void *, const void *)) __DARWIN_INODE64(scandir);
#ifdef __BLOCKS__
int scandir_b(const char *, struct dirent ***,
    int (^)(struct dirent *), int (^)(const void *, const void *)) __DARWIN_INODE64(scandir_b);
#endif /* __BLOCKS__ */
#endif /* not POSIX */

to this

int scandir(const char *, struct dirent ***,
    int (*)(const struct dirent *), int (*)(const struct dirent **, const struct dirent **)) __DARWIN_INODE64(scandir);
#ifdef __BLOCKS__
int scandir_b(const char *, struct dirent ***,
    int (^)(const struct dirent *), int (^)(const struct dirent **, const struct dirent **)) __DARWIN_INODE64(scandir_b) __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2);
#endif /* __BLOCKS__ */

So I suspect this build would also fail on other systems <10.8 due to this.

[kencu (Ken)]

Main (?only) reason for lirc is as a requirement for Audacious in default configuration.

Audacious builds through to completion when lirc is removed from the "full" set of default variants - perhaps a suggestion might be to leave lirc out of the "full" set of variants in audacious-plugins, and make lirc an optional variant?

[ctreleaven (Craig Treleaven)]

I would suggest that audacious-plugins be modified, at least temporarily, to disallow the +lirc variant where the OS is 10.8 or earlier. Both lirc and audacious-plugins require C++11 so, by default, both normally require OS X 10.9 or higher anyway.

Being that 10.8 was released more than 4.5 years ago, I suspect that lirc upstream will not be too excited about adding conditional code to fix such a problem.

I'm not fluent in C++. If someone can supply an appropriate patch for 10.8 and prior, I can add it to our lirc port.

[kencu (Ken)]

Replying to ctreleaven:

I would suggest that audacious-plugins be modified, at least temporarily, to disallow the +lirc variant where the OS is 10.8 or earlier.

10.7 or earlier. 10.8+ would appear to be OK.

I'm not fluent in C++. If someone can supply an appropriate patch for 10.8 and prior, I can add it to our lirc port.

I think it's not a trivial fix (like a cast). People seem to rewrite scandir for these older systems. Ugh. Don't see myself digging into that at the moment, but I see there is a replacement in glib that perhaps could be used <​https://fossies.org/dox/glibc-2.24/scandir_8c.html> if someone is so motivated.

For now I'm happy without lirc , and audacious works great without that bit of functionality.

[kencu (Ken)]

not presently fixable, and no progress after 17 months. I'll come back to this someday with a fix if one ever exists for it.

[jmroot (Joshua Root)]

In 74405bfa3c405e2c316d669fba0a0a744cc6dad5/macports-ports (master):

lirc: build fix for < 10.8

Fixes: #53314

[kencu (Ken)]

Yeah - why couldn't I see that? I learn a lot from you guys. Thanks.