It’s a missing symbol in a system library dynamically loaded by make. Testing this ‘make’ on its own, it appears this problem only occurs when make is called with the ‘-j’ option to run parallel jobs.
My workaround is to replace it with a dynamic link to /usr/bin/make, though I can’t be certain where this make actually came from.
This is a 2015 MacBook Pro, with OS and Xcode upgrades over the years.
Sure, it would be simple (though costly) to get a new(er) MacBook - but this one still serves my needs beautifully.
--> Generating Daisy module
Total compile time: 376.25ms
Compiling.../Users/robert/Library/plugdata/Toolchain/bin/arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000 -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER -include stm32h7xx.h -I../../libDaisy -I../../libDaisy/src/ -I../../libDaisy/src/sys -I../../libDaisy/src/usbd -I../../libDaisy/src/usbh -I../../libDaisy/Drivers/CMSIS/Include/ -I../../libDaisy/Drivers/CMSIS/DSP/Include -I../../libDaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../../libDaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../../libDaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I../../libDaisy/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I../../libDaisy/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc -I../../libDaisy/core/ -I../../libDaisy/Middlewares/Third_Party/FatFs/src -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/startup_stm32h750xx.d" -std=gnu11 -Wa,-a,-ad,-alms=build/startup_stm32h750xx.lst ../../libDaisy/core/startup_stm32h750xx.c -o build/startup_stm32h750xx.o
dyld: lazy symbol binding failed: Symbol not found: ___darwin_check_fd_set_overflow
Referenced from: /Users/robert/Library/plugdata/Toolchain/bin/make (which was built for Mac OS X 12.0)
Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: ___darwin_check_fd_set_overflow
Referenced from: /Users/robert/Library/plugdata/Toolchain/bin/make (which was built for Mac OS X 12.0)
Expected in: /usr/lib/libSystem.B.dylib
/Users/robert/Library/Caches/plugdata/temp_c162b607.sh: line 2: 13862 Abort trap: 6 /Users/robert/Library/plugdata/Toolchain/bin/make -j4 -f /Users/robert/Documents/plugdata/junk/daisy/source/Makefile GCC_PATH=/Users/robert/Library/plugdata/Toolchain/bin PROJECT_NAME=RF_tone
Thnx, we had another user in the Discord today with the same issue. Basically the toolchain binaries are not compatible with this version of MacOS. We’ll try to look for a solution, but no guarantees
Hi, I just got the Daisy Patch eurorack module and have been trying flash it with a simple patch I have made in Plugdata (knob1 changes the frequency of an oscillator…exciting). When I select the patch target board, it compiles and uploads, but nothing works. When I select Patch init target board it sort of works, but the audio is coming out of OUT 2 and the knob that is controlling the frequency is CTRL 2. This leads me to believe that the JSON that describes the Patch is not describing the Patch device I have.
The JSON in json2daisy appears to match the pinouts of the Patch in the Hardware repository( though they are off by 1. I can program this with device successfully with the web programmer and the examples, so I think the hardware is OK.
Is there a JSON file I should be using that describes my hardware? Is there something else going on? Thanks!
The JSON files do match. I have the same results when I use pd2dsy with my test file and the patch_test.pd example. I believe I am experiencing the same thing as this person. I will check the Discord to see if someone has a solution too.
I just played around with this for the first time last night, I’m really blown away!
Thanks for the incredible work, as a long time PD (and previously, Max) user I really can’t believe how far this project has come so quickly. The GUI is so comfortable!
I flashed a simple test patch to my daisy patch with no problems at all, it was a really exciting experience. (FWIW I’m working from linux via the arch package – also kudos to the plugdata team for going as far as creating a special pacman repo for the package!)
I’m so excited to use this for prototyping ideas with daisy. Thank you for this!
I miss Axoloti, too, and it will be a while before we get the compilable library up to Axoloti standards of abstraction, but it’s happening! There are already a ton of filters, for instance.
In my case, the version of make included in plugdata wouldn’t work on my old Mac OS, as I wrote above.
So, I bought a new M1 MacBook Air, which I haven’t unboxed yet. But, since I’m working on Eurorack, I want to use STLINK, but plugdata doesn’t do that.
Actually, the latest toolchain for the upcoming 0.7.0 release has a fix for MacOS 10.4 builds. This will hopefully help to keep old hardware alive!
Cross platform stlink support is definitely wanted! I’ve only played with stlink once myself and it’s definitely so much smoother experience than setting boot-loader mode every time!
Plugdata is the ‘bees knees’ (that’s a good thing)
Takumi’s videos on his own channel got me re-interested in pd, but he’s using a mac which makes pd look less hideous. Plugdata makes using pd much easier on the aesthetic sensibilities . Plus it is very useful and intuitive.
I’ve been prototyping a bit with stlink. The problem is that it doesn’t work with ROM or RAM optimized builds, which makes it only useful for very small programs.
So I’m not sure if this really is much of an improvement, since for any serious work (where stlink becomes really useful) you will want to have these size optimized builds … for which you can’t use stlink >_<
I have the Problem, that Midi-In-Information is not working with a very Simple PD-Patch on my Daisy-Pod using a notein, mtof and an osc~.
Is there anything special to be included or to be put into the pd-patch to get the Midi-Information of the TRS-Midiinput of the Pod?
. Plus it is very useful and intuitive.