brew reinstall --build-from-source --verbose --debug openFPGAloader not working on AppleSilicon

[jrrk2]

brew reinstall --build-from-source --verbose --debug openFPGAloader does not work on AppleSilicon under OSX 12.2.1

When installed as a binary, it does work but the formula is outdated. The actual error is in libusb which installs without errors, but when linked with openFPGAloader, fails with the following errors:

/opt/homebrew/Library/Homebrew/shims/mac/super/clang++ -O3 -DNDEBUG -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names  -framework CoreFoundation -framework IOKit CMakeFiles/openFPGALoader.dir/src/anlogic.cpp.o CMakeFiles/openFPGALoader.dir/src/anlogicBitParser.cpp.o CMakeFiles/openFPGALoader.dir/src/anlogicCable.cpp.o CMakeFiles/openFPGALoader.dir/src/ch552_jtag.cpp.o CMakeFiles/openFPGALoader.dir/src/dfu.cpp.o CMakeFiles/openFPGALoader.dir/src/dfuFileParser.cpp.o CMakeFiles/openFPGALoader.dir/src/dirtyJtag.cpp.o CMakeFiles/openFPGALoader.dir/src/efinix.cpp.o CMakeFiles/openFPGALoader.dir/src/efinixHexParser.cpp.o CMakeFiles/openFPGALoader.dir/src/fx2_ll.cpp.o CMakeFiles/openFPGALoader.dir/src/ice40.cpp.o CMakeFiles/openFPGALoader.dir/src/ihexParser.cpp.o CMakeFiles/openFPGALoader.dir/src/spiFlash.cpp.o CMakeFiles/openFPGALoader.dir/src/spiInterface.cpp.o CMakeFiles/openFPGALoader.dir/src/rawParser.cpp.o CMakeFiles/openFPGALoader.dir/src/usbBlaster.cpp.o CMakeFiles/openFPGALoader.dir/src/epcq.cpp.o CMakeFiles/openFPGALoader.dir/src/svf_jtag.cpp.o CMakeFiles/openFPGALoader.dir/src/jedParser.cpp.o CMakeFiles/openFPGALoader.dir/src/feaparser.cpp.o CMakeFiles/openFPGALoader.dir/src/display.cpp.o CMakeFiles/openFPGALoader.dir/src/jtag.cpp.o CMakeFiles/openFPGALoader.dir/src/ftdiJtagBitbang.cpp.o CMakeFiles/openFPGALoader.dir/src/ftdiJtagMPSSE.cpp.o CMakeFiles/openFPGALoader.dir/src/configBitstreamParser.cpp.o CMakeFiles/openFPGALoader.dir/src/ftdipp_mpsse.cpp.o CMakeFiles/openFPGALoader.dir/src/main.cpp.o CMakeFiles/openFPGALoader.dir/src/latticeBitParser.cpp.o CMakeFiles/openFPGALoader.dir/src/gowin.cpp.o CMakeFiles/openFPGALoader.dir/src/device.cpp.o CMakeFiles/openFPGALoader.dir/src/lattice.cpp.o CMakeFiles/openFPGALoader.dir/src/progressBar.cpp.o CMakeFiles/openFPGALoader.dir/src/fsparser.cpp.o CMakeFiles/openFPGALoader.dir/src/mcsParser.cpp.o CMakeFiles/openFPGALoader.dir/src/ftdispi.cpp.o CMakeFiles/openFPGALoader.dir/src/altera.cpp.o CMakeFiles/openFPGALoader.dir/src/bitparser.cpp.o CMakeFiles/openFPGALoader.dir/src/xilinx.cpp.o CMakeFiles/openFPGALoader.dir/src/xilinxMapParser.cpp.o CMakeFiles/openFPGALoader.dir/src/colognechip.cpp.o CMakeFiles/openFPGALoader.dir/src/colognechipCfgParser.cpp.o -o openFPGALoader  /opt/homebrew/lib/libftdi1.a /opt/homebrew/lib/libusb-1.0.a 

Undefined symbols for architecture arm64: "_SecTaskCopyValueForEntitlement", referenced from: _darwin_detach_kernel_driver in libusb-1.0.a(darwin_usb.o) "_SecTaskCreateFromSelf", referenced from: _darwin_detach_kernel_driver in libusb-1.0.a(darwin_usb.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation)

These functions seem to have been introduced at version 700 of the Interface to libusb. Perhaps that version is already obsolete for Monterey. Feel free to ignore this bug on grounds that the real problem is in libusb. Or do you think the problem should be raised with the HomeBrew authors ?

[trabucayre]

In fact I'm absolute not specialist of Apple's computers. Maybe @jeanthom or @chenrui333 are more able to answer about that. Is it not possible to use this formula ? Or at least following this procedure to try to build manually?

[jeanthom]

When installed as a binary, it does work but the formula is outdated

The Homebrew formula uses the latest "stable" version of openFPGALoader. Sure it isn't the latest unstable version, but it should work well enough.

Your issue looks similar to this one: https://githubmemory.com/repo/libusb/libusb/issues/931 Can you try to add "-framework Security" to the CMakeLists.txt at the end of this line? https://github.com/trabucayre/openFPGALoader/blob/master/CMakeLists.txt#L174

@trabucayre The above mentioned issue is caused by static linking of libusb on macOS. Are we using static libs on other platforms?

[chenrui333]

yeah, looks like the HEAD build failed for me as well, brew install --HEAD openfpgaloader (I am on a m1 machine)

Undefined symbols for architecture arm64:
  "_SecTaskCopyValueForEntitlement", referenced from:
      _darwin_detach_kernel_driver in libusb-1.0.a(darwin_usb.o)
  "_SecTaskCreateFromSelf", referenced from:
      _darwin_detach_kernel_driver in libusb-1.0.a(darwin_usb.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[trabucayre]

The Homebrew formula uses the latest "stable" version of openFPGALoader. Sure it isn't the latest unstable version, but it should work well enough.

I assume it's to use openFPGALoader with kintex and with new contributed boards so I suspect lastest stable is not enough...

@trabucayre The above mentioned issue is caused by static linking of libusb on macOS. Are we using static libs on other platforms?

On linux platforms: no (it's always possible to force using static libs but some distributions have stopped to provides .a). For windows I'm not sure but I think no.

[trabucayre]

I have checked all commits between v0.7.0 and HEAD. There is nothing about USB modifications... And no MAC computer to test.

[jrrk2]

Thanks for the tip, adding “-framework Security as Jean suggested did the trick. Now there only remains a runtime issue, “openFPGAloader is built without zlib support”. This is solved by reinstalling the home brew version of zlib.

[jeanthom]

@jrrk2 Thanks for trying this patch. I thought openFPGALoader had zlib on macOS already? What steps did you perform to get zlib decompression working?

[jrrk2]

All I did was (re)install the home brew version of zlib and then pkg-config picked it up.

[jeanthom]

I think we can close this issue?

[jrrk2]

I guess so, since it will be up to the Libusb maintener to fix it.

[jeanthom]

I don't think it's a libusb issue, We were statically linking libusb against openFPGALoader, which means we had to manually add the "Security" framework. #200 should fix everything by linking dynamically to libusb.

[trabucayre]

I'm agree I'm not sure it's a libusb issue, but it make sense to warn maintener to the need of this flag when it's used with static linking. I don't know policy with brew / macOS but when using pkg-config on linux box CFLAGS and LDFLAGS are filled with, as far I know, everything required to compile code.

[jeanthom]

According to https://github.com/libusb/libusb/issues/931, libusb has everything you need in its pkg-config description (see Ludovic Rousseau's comment). The issue was that we were manually doing the job of pkg-config by hardcoding the library path, compiler flags, etc.: https://github.com/trabucayre/openFPGALoader/blob/bbd755832df464326fe3614a257336ec47d31acd/CMakeLists.txt#L172-L181

Besides being a bad thing for all the things we discussed in this issue, it also prevents users with a different Homebrew prefix and MacPorts (another package manager for macOS) users from installing openFPGALoader without having to edit the CMakeLists.txt.

[trabucayre]

Sorry I have missed this aspect. So yes it's not something related to libusb. I everyone is okay I can close this issue?

[trabucayre]

@jeanthom since some time workflow fails for macos, but I'm unable to find howto fix it. Could you have a look? Thanks!