Build failed on El Capitan

[mav2287]

Tried to build this today on El Capitan and got the follow errors:

-- Build files have been written to: /Users/mav2287/xserve-frontpanel-master Scanning dependencies of target hwmond [ 33%] Building C object CMakeFiles/hwmond.dir/hwmond.c.o /Users/mav2287/xserve-frontpanel-master/hwmond.c:53:5: warning: 'libusb_set_debug' is deprecated [-Wdeprecated-declarations] libusb_set_debug(usb_context, LIBUSB_LOG_LEVEL_INFO); ^ /opt/local/include/libusb-1.0/libusb.h:1325:18: note: 'libusb_set_debug' has been explicitly marked deprecated here void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level); ^ 1 warning generated. [ 66%] Building C object CMakeFiles/hwmond.dir/cpu_usage.c.o [100%] Linking C executable hwmond Undefined symbols for architecture x86_64: "_objc_registerThreadWithCollector", referenced from: _darwin_event_thread_main in libusb-1.0.a(libusb_1_0_la-darwin_usb.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: [hwmond] Error 1 make[1]: [CMakeFiles/hwmond.dir/all] Error 2 make: *** [all] Error 2

[mav2287]

So I got it to run from a compiled version I downloaded from someone else, but I could not get it to compile. I am using Macports as a package manager and it put libusb in a different place than the compiled version expected it. To get the pre-compiled binary to run I had to put a symlink in so it could find libusb. ln -s /opt/local/lib/libusb-1.0.0.dylib /usr/local/opt/libusb/lib/libusb-1.0.0.dylib

[castvoid]

Hi,

I've made a change to the linking flags which I think might fix this. I don't have an ElCap environment to test the fix out myself, though.

If you do get a chance to try it out and it doesn't work, please feel free to re-open the issue!

Harry

[ryandesign]

I can confirm that that does fix the build when linking against a static libusb on older versions of macOS. I verified the issue existed on OS X 10.8 and that this fixed it. The issue did not exist on macOS 10.13 when using a static libusb, and did not exist on any version of macOS when using a dynamic libusb.

xserve-frontpanel is available in MacPorts now so that's an even easier way to install it.

[mav2287]

Just tested with 10.11 ( El Capitan ) and it does build, but with the following notes/warning.

CMake Warning (dev) at /opt/local/share/cmake-3.17/Modules/FindPackageHandleStandardArgs.cmake:272 (message):
  The package name passed to `find_package_handle_standard_args` (Libusb)
  does not match the name of the calling package (LibUSB).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  modules/FindLibUSB.cmake:114 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:18 (find_package)
This warning is for project developers.  Use -Wno-dev to suppress it.

-- Found Libusb: /opt/local/lib/libusb-1.0.a  
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/mav2287/downloads/xserve-frontpanel-master
Scanning dependencies of target hwmond
[ 33%] Building C object CMakeFiles/hwmond.dir/hwmond.c.o
/Users/mav2287/downloads/xserve-frontpanel-master/hwmond.c:53:5: warning: 'libusb_set_debug' is deprecated [-Wdeprecated-declarations]
    libusb_set_debug(usb_context, LIBUSB_LOG_LEVEL_INFO);
    ^
/opt/local/include/libusb-1.0/libusb.h:1325:18: note: 'libusb_set_debug' has been explicitly marked deprecated here
void LIBUSB_CALL libusb_set_debug(libusb_context *ctx, int level);
                 ^
1 warning generated.

@ryandesign I created and use this plist to keep it alive:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.xserve-frontpanel.daemon.plist</string>
    <key>RunAtLoad</key>
    <string>YES</string>
    <key>KeepAlive</key>
    <true/>
    <key>Program</key>
    <string>/xserve-frontpanel/hwmond</string>
</dict>
</plist>

That is loaded as root as soon as the machine loads. Are you doing something similar on Macports to ensure it runs as root at boot and is then kept alive?

[ryandesign]

Yes, MacPorts has a feature allowing ports to create launchd plists and the port I created does make use of that facility.