Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
henning opened this issue Feb 3, 2024 · 11 comments
Open

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

henning opened this issue Feb 3, 2024 · 11 comments

Comments

@henning
Copy link

henning commented Feb 3, 2024

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
Copy link

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
      image
  • 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

image
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
Copy link

Error Message & Offending chars

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

@unityconstruct
Copy link

in VSCODE
image

@unityconstruct
Copy link

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
Copy link

  • 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
Copy link

@henning

  • JUCE has a linux release 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.
  • 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
Copy link
Author

henning commented Feb 10, 2024

@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
Copy link

unityconstruct commented Feb 10, 2024

@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
Copy link

unityconstruct commented Feb 11, 2024

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
  • 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

image

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
Copy link

  • 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

  • and the crash report

  • 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
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants