#228 MacOS compilation issues

[C Treleaven]

With recently commited fixes, LIRC builds successfully on my system:

OS X 10.10.5
XCode 7.2

During the build, however, clang emits a number of warnings. Rather than try to enumerate them here, refer to the attached build log and search for "warning: ". The warnings include simple code correctness issues (unused variable, unused function, type mismatches), etc.

Also noted is that daemon is deprecated on OS X and has been for ~10 years. On OS X, daemons are run by the launchd system and are prohibited from daemonizing. Since LIRC provides --nodaemon flags, this hasn't been a problem. I doubt Apple will yank out daemon as it would break a lot of multi-platfrom systems. But you never know.

Some of the warnings are quite trivial and some may even be false positivies.

Offered for your consideration.

[Alec Leamas]

Most things looks like the can be postponed until next release. However, we have

audio.Tpo -c audio.c  -fno-common -DPIC -o .libs/audio.o
audio.c:523:6: warning: implicit declaration of function 'openpty' is    invalid in C99 [-Wimplicit-function-declaration]
    if (openpty(&master, &ptyfd, ptyName, 0, 0) == -1) {
        ^
1 warning generated.

Could you check if attached patch solves this?

[C Treleaven]

Sorry, no joy.

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I.. -I../lib -I../lib -I.. -DDARWIN -Wall -Wp,-D_FORTIFY_SOURCE=2 -I/opt/local/include -pthread -Wall -DPLUGINDOCS=\"/opt/local/share/doc/lirc/plugindocs\" -pipe -Os -arch x86_64 -MT audio.lo -MD -MP -MF .deps/audio.Tpo -c audio.c  -fno-common -DPIC -o .libs/audio.o
audio.c:525:6: warning: implicit declaration of function 'openpty' is invalid in C99 [-Wimplicit-function-declaration]
        if (openpty(&master, &ptyfd, ptyName, 0, 0) == -1) {
            ^
1 warning generated.

The configure tests seem to have worked. config.h includes

/* Define if util.h is installed */
#define HAVE_UTIL_H 1

and

/* defined if pty.h is available */
/* #undef HAVE_PTY_H */

Not sure what the problem is.

[Alec Leamas]

Not sure what the problem is.

Nor am I, but it looks bad. First, can you double-check that plugin/audio.c contains these lines:

#ifdef HAVE_UTIL_H
#include <util.h>
#endif

#ifdef HAVE_PTY_H
#include <pty.h>
#endif

Assuming this is OK, can you check if /usr/include/uitil.h contains openpty(...), possibly in a file included from util.h

[C Treleaven]

I confirm that those lines are in plugins/audio.c

/usr/include/util.h includes:

int openpty(int *, int *, char *, struct termios *,
             struct winsize *);

Is it possible that Lirc's own util.h is being found before /usr/include/util.h ?

[Alec Leamas]

Ah, what a good catch! This is certainly the issue, stay tuned!

[Alec Leamas]

New patches... but this time I have pushed a new macos branch since the patch will not apply cleanly (it's not at the top). Can you check the new macos branch, making a new clone (it's rebased).

[C Treleaven]

I confirm that the code builds (patch no longer applied) and that the plugins/audio.c warning is now gone.

[Alec Leamas]

We also have

configure: WARNING: 
python3 link is missing, re-configure using --enable-python3-fix or just
make a symlink

What this says is that the python3 command isn't available for users. While the build code uses the complete PYTHON as defined by ./configure, the installed tools relies on that the python3 command is available. Enabling the --enable-python3-fix configure option is the simple solution, but might possibly interfere with other packages. Packaging-wise I guess that lirc installing a system-wide pyhton3 command isn't ideal, but I have no other solution. Is there some python dependency which can be used? Can a python3 symlink be installed somewhere else?

[C Treleaven]

My port does two steps that I think get around this issue.

1) The port ensures that Python 3.4 is installed. During Lirc's configure stage, the port sets an environment variable to point to it: 'PYTHON=/opt/local/bin/python3.4'.

2) My port changes the shebang line in all of Lirc's python scripts (AFAIK) to reference the MacPorts Python 3.4:

post-patch {
    ...
    reinplace -locale C "s|#!/usr/bin/env python3\$|#!${pythonbin}|" \
        ${worksrcpath}/doc/data2hwdb \
        ${worksrcpath}/doc/data2table \
        ${worksrcpath}/doc/make_rel_symlink.py \
        ${worksrcpath}/tools/check_configs.py \
        ${worksrcpath}/tools/irdb-get \
        ${worksrcpath}/tools/lirc-setup/lirc-setup \
        ${worksrcpath}/tools/lircd-setup \
        ${worksrcpath}/tools/make_rel_symlink.py \
        ${worksrcpath}/tools/pronto2lirc
}

MacPorts uses TCL under the hood. Essentially this does a 'sed' on each of the scripts. The ${pythonbin} variable is set earlier to '/opt/local/bin/python3.4'.

This is a fairly common practise in MacPorts. Unless I've missed some scripts, I think this should work.

BTW, I was able to run the lirc-setup script with a graphical user interface. However, every time I tried to select a configuration, it seemed to come back as missing. Didn't spend much time on it. Once we get the patches worked out, I'll have another try.

[Alec Leamas]

OK, that should work. Perhaps we should actually fix this upstream, but let's leave it for now.

[Alec Leamas]

BTW, Most of these files are not installed: data2hdwb, data2table, make_rel_symlink(2), check_configs,

[Alec Leamas]

Since the package builds I'm closing this one. Please file new for bugs in the MacOS version if required. Thanks for all work!