MacOS testgui make error #151
Labels
No labels
3rdparty
Android
API
Author does not respond
bsd
bug
build system/CI
ci-virtual-device
CMake
Contributions Welcome
Core
dependencies
device-specific
documentation
don't_merge
duplicate
enhancement
Example
Haiku
hidraw
hotplug
info required
invalid
libusb
macOS
Misc
Not an issue
question
Release
Test
Test GUI
Windows
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-libusb/hidapi#151
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hardware: MacBook Pro, MacOS 10.15
Software: fox-toolkit installed with MacPorts
("./configure && make && make install" of fox toolkit on Mac fails with several files not found)
testgui % gmake -f Makefile-manual
g++ -I../hidapi -Wall -g -c
fox-config --cflagstest.cpp -o test.og++ -I../hidapi -Wall -g -c
fox-config --cflags-x objective-c++ mac_support_cocoa.m -o mac_support_cocoa.orm -Rf TestGUI.app
mkdir -p TestGUI.app
cp -R TestGUI.app.in/ TestGUI.app
g++ -Wall -g ../mac/hid.o test.o mac_support_cocoa.o
fox-config --libs-framework IOKit -framework CoreFoundation -framework Cocoa -L/usr/X11R6/lib -o hidapi-testguild: warning: directory not found for option '-L/usr/X11R6/lib'
./copy_to_bundle.sh
application/x-mach-binary; charset=binary
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump:
error: '/Users/xxx/Documents/Arduino/hidapi/testgui/TestGUI.app/Contents/MacOS/hidapi-testgui': Not a directory
#cp TestGUI.app/Contents/MacOS/hidapi-testgui TestGUI.app/Contents/MacOS/tg
#cp start.sh TestGUI.app/Contents/MacOS/hidapi-testgui
The unix executable file that is built, "hidapi-testgui", does run by double click on file in Finder or by using terminal command line "./hidapi-testgui"
hidapi-testgui will find and open a device and send and receive reports.
I think you're the first user of this GUI app for a long time (on macOS)
Can't promise me or anyone from the team is going to check on it any time soon
Feel free to try fixing it yourself and opening a PR - help is welcome
Works fine for me with the autotools build process (
foxis installed via homebrew as far as I can tell)But it looks like the manual Makefile is indeed broken
thanks @z3ntu, that's awesome you've checked it
we're ready to merge #152
@84Park would you care to check is it fixes the issue in your environment?
Thank you. I modified copy_to_bundle.sh with "mkdir -p $EXEPATH" and that removed the error reported in #151 (error: '/Users/xxx/Documents/Arduino/hidapi/testgui/TestGUI.app/Contents/MacOS/hidapi-testgui': Not a directory)
Good job!
https://github.com/mcuee/hidapi/releases
Here is a x64 binary snapshot tested under my Mac Mini M1 (with Rosetta 2). I am not so sure how to build the native ARM64 binary as the bundle seems to be a bit off.
The way I've been building for M1 (arm64) is to build a "fat binary" that contains both executables. It's pretty easy by passing in two
-archflags to CFLAGS. Here's howhidapitesterdoes it:github.com/todbot/hidapitester@eb8bae29a4The result is checkable with
file:(This was just added. I'm using this technique on a few other projects with success. I clearly need to fix the hidapitester CI now :-)
Nice tip. But I do not know how to apply the same tip to GUI applications which relies on multiple libraries.
I am using Homebrew and the auto-tools to build test-gui (it is not suppored by CMake). The issue is in the bundling portion that it does not know to bundle the right ARM64 version (/opt/homebrew/lib) of libjpeg.dylib and libtiff.dylib.
As a result, the GUI application hidapitest-gui is working, but not the TestGUI.app bundle.
Even if I copy the necessary dylib files to the TestGUI.app/Contents/MacOS folder to be in the same directory with hidapi-testgui, TestGui.app will still crash as it still wants to find /usr/local/lib files which are of x64 arch.
So my question is how to specify the dylib directory. In the command line, I can do that. But I do not know how to do that in the app bundle.
Full build-log for ARM64. "/Users/mcuee/bin/bin/hidapi-testgui" works just fine. But the "TestGUI.app" is not working.
Looks the warning about signature is fatal. The others may not be a real issue.
Crash log:
No such signature warning under x64 build.
There is apparently a differnce between an ARM64 build and x86_64 build. Probably this issue can not be sorted out without being a Apple macOS developer. I can self sign it but I am not so sure how to fix the bad signature issue of the dylib.
Apologies, I only really read your last post before I replied. The dual
-archCFLAGS must be done for all binaries being created (including shared libs). If you're using libraries you don't fully control or can specify the build style for, then you'll have to create two different executables.No problem. It is okay to use two different executables in this case.
Just wondering who knows how to fix the invalid signature problem on the ARM64 (Apple Silicon) side.
Try:
otool -l <your binary/executable>You'll get a list of all kind of things, including the list of dynamic libraries your binary links too statically (
LC_LOAD_DYLIBsection):/usr/lib/libSystem.B.dylib- there is no way to hack/inject the usage of those, unless replacing the file itself;@rpath/libhidapi.0.dylib; those are searched relatively to RPATH (or RUNPATH);RPATHs orRUNPATHs is always hardcoded into the binary itself (unlike in linux, where you configure ldconfig) -LC_RPATHsection;DYLD_LIBRARY_PATHis probably the only way to extend the list ofRPATHs (and Apple has deprecated its usage, and it is really hard to use it properly nowadays; it is a separate topic - I won't start it now), but even it won't work for dependencies that are listed as an absolute paths;The only way to tweak you binary to use propper set of libraries (after it was built/linked) - is to use
install_name_tool, either by-change <old> <new>the path to dependent library or by-delete_rpath <old>/-add_rpath <new>list orRPATHwhere to search for the dependent libraries.That of course unvalidates the file signature, so it has to be done before signing.
@mcuee I haven't tried to describe the full story of how this all things works on macOS, but this should be enough for you to play around and try to make it work.
Thanks. I will try the tip to see if I can get it work or not.
This diff fixed the issue for me under my Mac Mini M1 -- at least I can run the TestGUI.app now, even if I copy the app to the /Application directory.
The two warnings does not seem to cause issues.
That being said, I think it is not properly done as the libhidapi.0.dylib is hardcoded to "/Users/mcuee/bin/lib/libhidapi.0.dylib" which I installed to as part of the build process.
click for more details of otool output
Yeah, it isn't.
To build it properly - a lot of tweaking need to be done for autotools scripts, which I'd rather not touch.
CMake build off-the-box likely won't properly work too, but CMake has a lot of convetient machanism to configure it easily.
I will do so if/when we have Qt-based GUI.
I will still keep this issue closed for now. Ad the testgui build itself is okay and runs properly under macOS (x64 and ARM64), only the application bundle is not generated properly.
I still have this issue, is there already a solution?
So I'm trying to use python ctypes to load the built obj file.
this then gives me a number of errors; but an important (I feel) error reads
I built using the guide to clone, cd mac,
make -f Makefile-manualIs this some weirdo OSX security issue, or something else?
The sample program builds and runs enumerating devices, so I don't doubt that hidapi works if I call it from C
Now it failed to build with latest macOS 26.4.1.