Linux build results in error "target pattern contains no '%'"

[henning]

After finding out that I need to be inside the directory Builds/LinuxMakefile/
before i run build.sh, then also need to install libcurl and alsa-lib development packages, the linux build still fails for me at:

$ ./build.sh 
CTRLR[linux]: Building for x86_64, JOBS 16
Makefile:336: *** target pattern contains no '%'.  Stop.
CTRLR[linux]: build failed

What could I be missing?

[unityconstruct]

Hey brother,

• TDLR;
  • attached a buildfile that JUCE must produce that looks like architecture detection that is normally done in VS2019 manually before builds
  • CtrlrPanel.ccp will cause build failure due to invalid chars aroudn line 336(366?) at a bunch of property statements
  • ||!!property <-- !! denotes the non-printable chars.. just delete & add space(s).. should be 3 total, but I did it to all property statements there to cut to the chase.
• about to rerun build & see if this is the only thing

---

• Working on initial builds on Win10, with SharedCode just building successful.

• On windows, build prep includes some steps using Projucer.exe:

  • Set Global Paths to reference the CrltrX/JUCE path
  • Open CtrlrX/CtrlrX.jucer project in Projucer
  • Export by selecting TargetIDE, then click EXPORT
    

• From what I gather, Projucer creates SLN/PROJ/Build files referencing JUCE deps - and I assume maybe bridging cpp/lua files

• Looking at my windows footprint & a new clone on my linux box and I see a missing Builds/LinuxMakefile/make_helpers/arch_detection.cpp

• Attached that zipped folder

• I'm certain build prep is required to reference those JUCE libraries, but unclear if there's Linux scripts to use in lieu of the Projucer steps as in Windows.

• in any case, adding that file allowed build to proceed

data/git/CtrlrX/Builds/LinuxMakefile$ ./build.sh 
CTRLR[linux]: Building for x86_64, JOBS 8
Compiling include_juce_audio_plugin_client_VST2.cpp
Compiling class.cpp
Compiling class_info.cpp
Compiling class_registry.cpp

• CtrlrPanel.ccp has invalid chars that just need to be deleted & replaced with spaces around line 366
• I'll let you know if that makes everything happy

LinuxMakefile.zip

#if defined(__arm__) || defined(__TARGET_ARCH_ARM) || defined(_M_ARM) || defined(_M_ARM64) || defined(__aarch64__) || defined(__ARM64__)

  #if defined(_M_ARM64) || defined(__aarch64__) || defined(__ARM64__)
    #error JUCE_ARCH aarch64
  #elif (defined(__TARGET_ARCH_ARM) && __TARGET_ARCH_ARM == 8) || defined(__ARMv8__) || defined(__ARMv8_A__)
    #error JUCE_ARCH armv8l
  #elif (defined(__TARGET_ARCH_ARM) && __TARGET_ARCH_ARM == 7) || defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) || defined(__ARM_ARCH_7R__) || defined(__ARM_ARCH_7M__) || defined(__ARM_ARCH_7S__) || defined(_ARM_ARCH_7) || defined(__CORE_CORTEXA__)
    #error JUCE_ARCH armv7l
  #elif (defined(__TARGET_ARCH_ARM) && __TARGET_ARCH_ARM == 6) || defined(__ARM_ARCH_6__) || defined(__ARM_ARCH_6J__) || defined(__ARM_ARCH_6T2__) || defined(__ARM_ARCH_6Z__) || defined(__ARM_ARCH_6K__) || defined(__ARM_ARCH_6ZK__) || defined(__ARM_ARCH_6M__)
    #error JUCE_ARCH armv6l
  #elif (defined(__TARGET_ARCH_ARM) && __TARGET_ARCH_ARM == 5) || defined(__ARM_ARCH_5TEJ__)
    #error JUCE_ARCH armv5l
  #else
    #error JUCE_ARCH arm
  #endif

[unityconstruct]

Error Message & Offending chars

• ran into this after adding the attached cpp file
• about to fix those chars & rerun
  

[unityconstruct]

in VSCODE

[unityconstruct]

build failure on liberty - looking into it, prob just missing package

Linking CtrlrX - Shared Code
Linking CtrlrX - VST
Linking CtrlrX - VST3
Linking CtrlrX - Standalone Plugin
/usr/bin/ld/usr/bin/ld: cannot find : cannot find -liberty-liberty: : No such file or directoryNo such file or directory

/usr/bin/ld: cannot find -liberty: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:347: build/Ctrlr.so] Error 1
make: *** Waiting for unfinished jobs....
collect2: error: ld returned 1 exit status
make: *** [Makefile:370: build/Ctrlr] Error 1
collect2: error: ld returned 1 exit status
make: *** [Makefile:359: build/Ctrlr.vst3/Contents/x86_64-linux/Ctrlr.so] Error 1
CTRLR[linux]: build failed

[unityconstruct]

• build successful after installing libiberty-dev
• so add file, fix char issues in CtrlrPanel.cpp

Compiling include_juce_audio_plugin_client_VST3.cpp
Compiling include_juce_audio_plugin_client_Standalone.cpp
Linking CtrlrX - Shared Code
Linking CtrlrX - VST
Linking CtrlrX - VST3
Linking CtrlrX - Standalone Plugin
/usr/bin/ld/usr/bin/ld: cannot find : cannot find -liberty-liberty: : No such file or directoryNo such file or directory

/usr/bin/ld: cannot find -liberty: No such file or directory
collect2: error: ld returned 1 exit status
make: *** [Makefile:347: build/Ctrlr.so] Error 1
make: *** Waiting for unfinished jobs....
collect2: error: ld returned 1 exit status
make: *** [Makefile:370: build/Ctrlr] Error 1
collect2: error: ld returned 1 exit status
make: *** [Makefile:359: build/Ctrlr.vst3/Contents/x86_64-linux/Ctrlr.so] Error 1
CTRLR[linux]: build failed

~/data/git/CtrlrX/Builds/LinuxMakefile$ apt search liberty
~/data/git/CtrlrX/Builds/LinuxMakefile$ sudo apt install binutils-dev
[sudo] password for setup:      
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
binutils-dev is already the newest version (2.38-4ubuntu2.5).
0 upgraded, 0 newly installed, 0 to remove and 307 not upgraded.

~/data/git/CtrlrX/Builds/LinuxMakefile$ sudo apt install libiberty-dev
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  libiberty-dev
0 upgraded, 1 newly installed, 0 to remove and 307 not upgraded.
Need to get 169 kB of archives.
After this operation, 678 kB of additional disk space will be used.
Get:1 http://babylon.cs.uh.edu/mirror-sites/ubuntu jammy/main amd64 libiberty-dev amd64 20211102-1build1 [169 kB]
Fetched 169 kB in 0s (566 kB/s)       
Selecting previously unselected package libiberty-dev:amd64.
(Reading database ... 861697 files and directories currently installed.)
Preparing to unpack .../libiberty-dev_20211102-1build1_amd64.deb ...
Unpacking libiberty-dev:amd64 (20211102-1build1) ...
Setting up libiberty-dev:amd64 (20211102-1build1) ...

~/data/git/CtrlrX/Builds/LinuxMakefile$ ./build.sh 
CTRLR[linux]: Building for x86_64, JOBS 8
Linking CtrlrX - VST
Linking CtrlrX - VST3
Linking CtrlrX - Standalone Plugin
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
CTRLR[linux]: build succeeded

[unityconstruct]

@henning

• JUCE has a linux release 6.0.8
  • https://github.com/juce-framework/JUCE/releases/tag/6.0.8
• The attached file above was generated from the Windows JUCE Projucer application
• There's a Windows 10 Compiling Guide I just ported from PDF that walks through the Projucer steps, but is for WINDOWS.
  • I just tried to follow those steps using the LINUX release of JUCE Projucer
  • I couldn't get the export button to ENABLE
    • I saw some paths referencing juce instead of JUCE, and updated the once I saw, but the export button STILL didn't ENABLE
  • https://github.com/unityconstruct/CtrlrXY/wiki/Building-Ctrlr-on-Windows%5BPENDING%5D
• These steps may not even be needed for Linux builds - perhaps the various build-related *.sh files are enough for config...
  • These Projucer steps MAY only be needed when actually developing the project in Visual Studio

Can't guarantee I know enough to figure it out, but I'm trying to come up to speed on this platform, so will likely look into it further. My next try will involve pulling repo again (or reverting the git changes) and taking a look at the *.sh files to see if any would create the above-mentioned cpp file - or have applicable paths.

Hope some of this helps!

[henning]

@unityconstruct thanks for this extensive research! I actually didn't think it would be all that much, I thought I'd remember that some people were working on the Linux builds a year ago and that i saw messages flying by that they were successful.

I will try to look into these things when I have a few hours to thoroughly read and try these things.

[unityconstruct]

@unityconstruct thanks for this extensive research! I actually didn't think it would be all that much, I thought I'd remember that some people were working on the Linux builds a year ago and that i saw messages flying by that they were successful.

I will try to look into these things when I have a few hours to thoroughly read and try these things.

• I was able 'build' after adding that one cpp file (after fixing CtrlrPane.cpp 3 bad chars thing), BUT it would enter a crash loop immediately when attempting to start it...
• I think the new changes are likely involved at least in part - given that there is new JUCE files/config.
• A test would probably involve trying to build 5.6.28 on linux. This would at least 'cut the deck of cards in half' & eliminate possible root causes significantly. I'm NEW to the game as of like 2 weeks ago - though pulled & used .201 release years ago as an end user. I neither have a good grasp of the full architecture nor how JUCE/boost/luabind all interact & what level - but fully intend on fixing that.
• if you're a casual user, i'd probably just report your findings on if 5.6.28 builds, then enter a holding pattern
• There might be some triage/debugging steps available for the more intrepid person

JUCE + Ctrlr

• JUCE provides all the cool stuff like audio/UI/MIDI c++ classes with I think 'luabind' glue...
• what's more, it provides these in a way to allow building for different OS's - which lends itself to the VSTi situation
• Ctrl seems to add its own C++ its own classes/luabind exposing those JUCE objects
• panel dev is basically adding these JUCE/Crtlr UI elements then using lua to drive things.

point being that since this .29 release alters JUCE things, linux build utils might need updates...

• if you're linux savvy, another thing to do is a pull .28 & .29 to separate folders & do file compare - specifically looking for:
  • .sh files
  • then all files in general
• Krudaser has Dir Compare Util [CTR+Y] that makes this go quickly
• then I'd peek into the .sh files OUTSIDE the /Source folder first & see if anything obvious comes to mind.

• meh... compare branches would make this a two click process vs 1000 steps

[unityconstruct]

update

• poked around & after chasing a few ghosts/dead-ends, certain the root cause is missing /Builds/LinuxMakefile/make_helpers/arch_detection.cpp
• there is an EXACT copy of this file at /JUCE/extras/Build/CMake/juce_runtime_arch_detection.cpp
  • juce_runtime_arch_detection.cpp.zip
• workaround might simply be either moving/copying this file to that location permanently in the repo OR
  • add COPY(cp) statement in the /build.sh for that file, renaming it in the process.
  • this seems the less invasive approach until its known how the issue came to be
• When I built for windows 10, Projucer apparently created this file in /Builds/LinuxMakefile, but is useless for that particular build process ( picking this brainstorm at bottom )

Makefile

  JUCE_VST3DIR := Ctrlr.vst3
## line52
  VST3_PLATFORM_ARCH := $(shell $(CXX) `make_helpers/arch_detection.cpp` 2>&1 | tr '\n' ' ' | sed "s/.*JUCE_ARCH \([a-zA-Z0-9_-]*\).*/\1/")
  JUCE_VST3SUBDIR := Contents/$(VST3_PLATFORM_ARCH)-linux
...

...
  JUCE_LDFLAGS_VST3 := -shared -Wl,--no-undefined
  JUCE_VST3DIR := Ctrlr.vst3
## line94
  VST3_PLATFORM_ARCH := $(shell $(CXX) make_helpers/arch_detection.cpp 2>&1 | tr '\n' ' ' | sed "s/.*JUCE_ARCH \([a-zA-Z0-9_-]*\).*/\1/")
  JUCE_VST3SUBDIR := Contents/$(VST3_PLATFORM_ARCH)-linux
  JUCE_TARGET_VST3 := $(JUCE_VST3DIR)/$(JUCE_VST3SUBDIR)/Ctrlr.so

REAL Root Cause

• willing to bet this got disrupted long time ago & its just showing up again with latest project activity
  • This could as simple as a few loose ends with the JUCE migration years back
  • /JUCE/extras/Build/CMake/juce_runtime_arch_detection.cpp looks 100% STATIC, not generated - being a simple utility to sniff out architecture for the Makefile

5.6.0 Build Fails

• was looking to establish happy, successful baseline, then start comparing things with a healthy fileset
• copying the arch_detection.cppto LinuxMakefile/make_helpers got things moving along great...
• until Linking Ctrlr - Standalone Plugin
• reference errors start showing up with keys.cpp -> X*

/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `createKeyEvent(_XDisplay*, unsigned long&, unsigned long&, bool, int, int)':
keys.cpp:(.text+0x4e): undefined reference to `XKeysymToKeycode'

• sure makes me thing of XCode, but linux has all sorts of stuff like X11, so may have nothing to do with XCode
• At this point, there definitely an issue with that arch_detection thing not being where it needs to
  • could be simple commit boo-boo
  • or build process actually changed when all this got a facelift years back
• This MIGHT be the only issue, with the build failure being missing deps are something stupid on my system - and I tend to lean that directly usually - but given there is one KNOWN issue with that missing file...
• Lastly, there could be MULTIPLE things going on, so not ruling out that the initial JUCE Ctrlr.juice config committed to repo could be setting us up for failure. I don't have enough experience with builds at this point.
• I got something to build on linux 2 days ago & I want to say it was on .29, & while it would run.. it entered into a 'crash loop'.
• So going to pull .29-master, copy that file over & give it another go to collect data/trends.

Compiling include_juce_gui_extra.cpp
Compiling include_juce_audio_plugin_client_VST3.cpp
Compiling include_juce_audio_plugin_client_Standalone.cpp
Linking Ctrlr - Shared Code
Linking Ctrlr - VST
Linking Ctrlr - VST3
Linking Ctrlr - Standalone Plugin
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: build/Ctrlr.a(lua_260ca39c.o): in function `os_tmpname':
lua.c:(.text+0x1d075): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `createKeyEvent(_XDisplay*, unsigned long&, unsigned long&, bool, int, int)':
keys.cpp:(.text+0x4e): undefined reference to `XKeysymToKeycode'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `ctrlr_sendKeyPressEvent(juce::KeyPress const&)':
keys.cpp:(.text+0xb9): undefined reference to `XOpenDisplay'
/usr/bin/ld: keys.cpp:(.text+0xd5): undefined reference to `XDefaultRootWindow'
/usr/bin/ld: keys.cpp:(.text+0xea): undefined reference to `XGetInputFocus'
/usr/bin/ld: keys.cpp:(.text+0x19f): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x23b): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x247): undefined reference to `XCloseDisplay'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `createKeyEvent(_XDisplay*, unsigned long&, unsigned long&, bool, int, int)':
keys.cpp:(.text+0x4e): undefined reference to `XKeysymToKeycode'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `ctrlr_sendKeyPressEvent(juce::KeyPress const&)':
keys.cpp:(.text+0xb9): undefined reference to `XOpenDisplay'
/usr/bin/ld: keys.cpp:(.text+0xd5): undefined reference to `XDefaultRootWindow'
/usr/bin/ld: keys.cpp:(.text+0xea): undefined reference to `XGetInputFocus'
/usr/bin/ld: keys.cpp:(.text+0x19f): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x23b): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x247): undefined reference to `XCloseDisplay'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `createKeyEvent(_XDisplay*, unsigned long&, unsigned long&, bool, int, int)':
keys.cpp:(.text+0x4e): undefined reference to `XKeysymToKeycode'
/usr/bin/ld: build/Ctrlr.a(keys_f237af18.o): in function `ctrlr_sendKeyPressEvent(juce::KeyPress const&)':
keys.cpp:(.text+0xb9): undefined reference to `XOpenDisplay'
/usr/bin/ld: keys.cpp:(.text+0xd5): undefined reference to `XDefaultRootWindow'
/usr/bin/ld: keys.cpp:(.text+0xea): undefined reference to `XGetInputFocus'
/usr/bin/ld: keys.cpp:(.text+0x19f): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x23b): undefined reference to `XSendEvent'
/usr/bin/ld: keys.cpp:(.text+0x247): undefined reference to `XCloseDisplay'
collect2: error: ld returned 1 exit status
make: *** [Makefile:371: build/Ctrlr] Error 1
make: *** Waiting for unfinished jobs....
collect2: error: ld returned 1 exit status
make: *** [Makefile:348: build/Ctrlr.so] Error 1
collect2: error: ld returned 1 exit status
make: *** [Makefile:360: build/Ctrlr.vst3/Contents/x86_64-linux/Ctrlr.so] Error 1
CTRLR[linux]: build failed

Oh yeah... forgot - the other reason I think this its build config thing

• Builds/Generated/Linux/Standalone <-- doesn't exist anymore

Linux

A build.sh script is provided in `Builds/Generated/Linux/Standalone`, a symlink of that
script is location in Builds/Generated/Linux/VST and is used to create a precompiled header
and then to trigger the build using make. You can do that manualy if you like just have
a look at the script, it's really simple.

FYI: I'm not all panicky with getting Linux up, so there is no urgency on my end to resolve anything much less look at it. Sounds like Linux ( while my first only love ) is the odd man out & 1000% more important to get comfortable with the other OS stability & resolving any issues. I'm only looking into this really to take any pressure off damien that might be there... Minimally, .29 did NOT introduce the issue.. seeing this all on FRESH 5.6.0 .....

Tata-Fa-Nana!
~ The Village Idiot

[unityconstruct]

• ok, so 5.6.29-master builds nice n fast
• CtrlrPanel.cpp bad-char issue fixed
• Getting crash loop though..

/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x64680e) [0x55df15c6a80e]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x57d9e9) [0x55df15ba19e9]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x634311) [0x55df15c58311]
/lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7f4bdac6f520]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x8fd8ba) [0x55df15f218ba]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x8fdc88) [0x55df15f21c88]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0xa455d8) [0x55df160695d8]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0xa4e113) [0x55df16072113]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0xa4ecd6) [0x55df16072cd6]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x93bb29) [0x55df15f5fb29]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x9271e6) [0x55df15f4b1e6]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x928608) [0x55df15f4c608]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x928884) [0x55df15f4c884]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x57f0e3) [0x55df15ba30e3]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x57e472) [0x55df15ba2472]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x6d140e) [0x55df15cf540e]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x2bb12f) [0x55df158df12f]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7f4bdac56d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7f4bdac56e40]
/home/setup/data/git-ctrlr/CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/Ctrlr(+0x57d6e5) [0x55df15ba16e5]�

• a /CtrlrX-5.6.29-test/Builds/LinuxMakefile/build/intermediate/Release/ folder got created - not sure if that normal
  attached its ls -la

  • dir.txt

• and the crash report

  • Ctrlr.crash.txt

• BinaryData_ce4232d4.d

  • might be simple juicer config, but linux builds hisorically didn't need to do the Projucer steps ( presumably only needed to config VStudio for dev work + WinBuilding
    • but wudda I know!

build/intermediate/Release/BinaryData_ce4232d4.o: \
 ../../JuceLibraryCode/BinaryData.cpp

• shutting up now :-P

[windowsrefund]

This looked like a cool project. Moving on...

[muxy23]

Okay let me add something to this.
I am on 6.12.8-arch1-1 Arch Linux and I just used the master branch (5.6.30?).
I've got the same issue at first and started to troubleshoot, made the directory make_helpers and copied the arch_detection.cpp
After this somewhat gave me progress, I've unzipped the boost.zip in Source/Misc/boost after which the building process finally started.

The next issue I've run in to, was that it had issues linking the VST. It tried using libbfd.a from a path that didn't exist for me: /usr/lib/gcc/x86_64-pc-linux-gnu/14.2.1/../../../../lib/libbfd.a. After finding, that the libbfd.a was in /usr/lib/libbfd.a I've had a look into the Makefile.

Honestly didn't really understand, where it got the nonexistent path from, but I did some modifications and added the path to the /usr/lib/libbfd.a and some libraries (sframe, zstd) it couldn't reference and ended up with adding this to LDFLAGS and LDLIBS after recompiling a few times:

...
  JUCE_CPPFLAGS_VST :=  "-DJucePlugin_Build_VST=1" "-DJucePlugin_Build_VST3=0" "-DJucePlugin_Build_AU=0" "-DJucePlugin_Build_AUv3=0" "-DJucePlugin_Build_RTAS=0" "-DJucePlugin_Build_AAX=0" "-DJucePlugin_Build_Standalone=0" "-DJucePlugin_Build_Unity=0"
  JUCE_CFLAGS_VST := -fPIC -fvisibility=hidden
  LDFLAGS += -L/usr/lib -lbfd -liberty -lopcodes -lsframe -lzstd
  LDLIBS += -lbfd -liberty -lopcodes -lsframe -lzstd
  JUCE_LDFLAGS_VST := -shared -Wl,--no-undefined
  JUCE_TARGET_VST := Ctrlr-Debug.so
  JUCE_VSTDESTDIR := $(HOME)/.vst
  JUCE_COPYCMD_VST := $(JUCE_OUTDIR)/Ctrlr-Debug.so $(JUCE_VSTDESTDIR)
...

(not sure if the position of LDFLAGS and LDLIBS matters and if LDLIBS is even needed)

Then I just compiled it again, and voila. Like magic it finished compiling and the Ctrlr-Debug executable and VST in Builds/LinuxMakefile/build and boot up. The VST is in its corresponding folder in home and everything works fine in my DAW (renoise)

Maybe this helps someone, maybe this is not the right way of doing it or the best way, but it worked for me :)

and thanks to Copilot for helping me find the right path lol

[unityconstruct]

@muxy23 nice! I had Ctrlr *.201 building on Linux, but don't think I ever got it going on CtrlrX. Might give your notes a try soon as I much prefer dev on Linux

maybe this is not the right way of doing it or the best way
one might say the right way is defined mostly by successful end result 😜