surge-synthesizer / surge

Synthesizer plug-in (previously released as Vember Audio Surge)
https://surge-synthesizer.github.io/
GNU General Public License v3.0
3.1k stars 395 forks source link

Looking to fix and bump failing build for Surge 1.7.1 to Surge-XT 1.3.2 on Guix #7662

Closed Ashvith10 closed 3 months ago

Ashvith10 commented 3 months ago

On Guix, the package for Surge fails to build, and I can't seem to figure out why, expect for maybe a deduction that it breaks on GCC 13 - here's the logs on the main build farm for Guix. I've also tried building 1.9.0 locally, and it still fails.

Now, the good news is that, most probably due to the JUCE port, Surge-XT builds I've run locally don't fail. However, that's a false positive, because sure, it does save the presets and examples, however, it does not save the LV2 and VST3 files. I just can't seem to figure out what could be the cause of this. Here's the diff for guix channels expression I've modified:

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index 14adf46401..94120ce959 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -1362,16 +1362,16 @@ (define-public fluida-lv2
 a frontend for fluidsynth.")
    (license license:gpl2+)))

-(define-public surge-synth
+(define-public surge-xt
   (package
-   (name "surge-synth")
-   (version "1.7.1")
+   (name "surge-xt")
+   (version "1.3.2")
    (source
      (origin
        (method git-fetch)
         (uri (git-reference
                (url "https://github.com/surge-synthesizer/surge")
-               (commit (string-append "release_" version))
+               (commit (string-append "release_xt_" version))
                (recursive? #t))) ; build system expects modules to be there
         (file-name (git-file-name name version))
         (sha256
@@ -1405,10 +1405,10 @@ (define-public surge-synth
               (mkdir-p lv2)
               (mkdir-p vst3)
               ;; Install LV2 plugin.
-              (copy-recursively "surge_products/Surge.lv2"
+              (copy-recursively "surge_xt_products/Surge.lv2"
                                 (string-append lv2 "/Surge.lv2"))
               ;; Install VST3 plugin.
-              (copy-recursively "surge_products/Surge.vst3"
+              (copy-recursively "surge_xt_products/Surge.vst3"
                                 (string-append vst3 "/Surge.vst3"))
               ;; Install data.
               (copy-recursively (string-append src "/resources/data")

Should I be adding any debug flags to enable LV2, VST3 and standalone build? And under which folder are they specifically built?

baconpaul commented 3 months ago

So first things surge xt and surge are different products intended to exist side by side. On many places we have them as two packages - I don’t know what is appropriate for guix, whose existence I learned about reading this ticket

for lv2 and vst3 there are cmake time options - vst3 is in by default but lv2 requires https://github.com/surge-synthesizer/surge/blob/086e0a686bc012b404c6533240e3f7a3c4c63614/src/CMakeLists.txt#L9 at first cmake

im not sure which cmake target you are building but the distribution target with above set should build vst3 lv2 clap and standalone on Linux if your code is unmodified

baconpaul commented 3 months ago

Oh and that comment about lv2 build crashing is resolved but the lv2 still works less well than the vst3 or clap so we have it as an opt in

baconpaul commented 3 months ago

Oh also the error in that massive massive build log is

In file included from /tmp/guix-build-surge-synth-1.7.1.drv-0/source/vstgui.surge/vstgui/lib/cbitmap.h:8, from /tmp/guix-build-surge-synth-1.7.1.drv-0/source/vstgui.surge/vstgui/vstgui.h:9, from /tmp/guix-build-surge-synth-1.7.1.drv-0/source/src/common/gui/vstcontrols.h:3, from /tmp/guix-build-surge-synth-1.7.1.drv-0/source/src/common/gui/CHSwitch2.h:17, from /tmp/guix-build-surge-synth-1.7.1.drv-0/source/src/common/gui/CHSwitch2.cpp:16: /tmp/guix-build-surge-synth-1.7.1.drv-0/source/vstgui.surge/vstgui/lib/vstguifwd.h:17:49: error: ‘numeric_limits’ is not a member of ‘std’ 17 | static constexpr uint32_t kStreamIOError = std::numeric_limits::max ();

which looks like vstgui was fragile wrt numeric limits and is missing a header. Probably fix that with a -I if you want

Ashvith10 commented 3 months ago

@baconpaul I'm still not sure if I understand what you mean by Surge and Surge XT being different? I was under the impression that Surge XT is the JUCE port that succeeds Surge. Is Surge still being maintained?

Here's the new diff for the changes in Scheme expressions:

diff --git a/gnu/packages/music.scm b/gnu/packages/music.scm
index 14adf46401..c9554d08b0 100644
--- a/gnu/packages/music.scm
+++ b/gnu/packages/music.scm
@@ -1362,26 +1362,32 @@ (define-public fluida-lv2
 a frontend for fluidsynth.")
    (license license:gpl2+)))

-(define-public surge-synth
+(define-public surge-xt
   (package
-   (name "surge-synth")
-   (version "1.7.1")
+   (name "surge-xt")
+   (version "1.3.2")
    (source
      (origin
        (method git-fetch)
         (uri (git-reference
                (url "https://github.com/surge-synthesizer/surge")
-               (commit (string-append "release_" version))
+               (commit (string-append "release_xt_" version))
                (recursive? #t))) ; build system expects modules to be there
         (file-name (git-file-name name version))
         (sha256
          (base32
-          "1jhk8iaqh89dnci4446b47315v2lc8gclraygk8m9jl20zpjxl0l"))))
+          "0b5ff4f6g22i6a8wmk7qzr3vwdz284sfcg9pig15gxl77739kh5g"))))
    (build-system cmake-build-system)
    (arguments
-    `(#:tests? #f ; no tests included
+    (list
+     #:configure-flags
+     #~(list "-DCMAKE_BUILD_TYPE=Release"
+             "-DSURGE_BUILD_LV2=TRUE"
+             (string-append "-DCMAKE_INSTALL_PREFIX="
+                            (assoc-ref %outputs "out")))
+      #:tests? #f ; no tests included
       #:phases
-      (modify-phases %standard-phases
+      #~(modify-phases %standard-phases
         (add-after 'unpack 'replace-python
           (lambda* (#:key inputs outputs #:allow-other-keys)
             (substitute* "CMakeLists.txt"
@@ -1405,18 +1411,23 @@ (define-public surge-synth
               (mkdir-p lv2)
               (mkdir-p vst3)
               ;; Install LV2 plugin.
-              (copy-recursively "surge_products/Surge.lv2"
-                                (string-append lv2 "/Surge.lv2"))
+              (copy-recursively "surge_xt_products/Surge.lv2"
+                                (string-append lv2 "/Surge XT.lv2"))
               ;; Install VST3 plugin.
-              (copy-recursively "surge_products/Surge.vst3"
-                                (string-append vst3 "/Surge.vst3"))
+              (copy-recursively "surge_xt_products/Surge.vst3"
+                                (string-append vst3 "/Surge XT.vst3"))
               ;; Install data.
               (copy-recursively (string-append src "/resources/data")
                                 (string-append share "/Surge"))
               #t))))))
    (inputs
-    (list cairo
+    (list alsa-lib
+          cairo
+          jack-2
+          libxcursor
+          libxinerama
           libxkbcommon
+          libxrandr
           python
           xcb-util
           xcb-util-cursor

About the Surge XT build, I tried it again, and it looks like I should've set the build type to 'Release', which actually populates the surge_xt_products directory. I'm not sure if I should have added the install prefix flag, but I did it, just because other Guix projects have also included them.

Some of it is my fault - that I failed to correct build files by renaming it from "Surge" to "Surge XT". However, I think I've noticed a bug in Guix, that is, it should fail the build immediately, when the files aren't available - but it does not - which is beyond the scope of Surge maintainers, but I'll have to ask the Guix folks about this.

Surge also builds CLAP plugins - I am not aware of any open-source DAW that supports CLAP, but I don't see any demerits to including them. With that being said, which directory do CLAP plugins go on Linux?

baconpaul commented 3 months ago

surge xt is not replacement compatible with surge in daw projects so most folks have both installed if they used surge so archival projects still render. Replacing surge with surge-xt silently on a system would be a breaking change with no remediation for DAW users.

QTractor supports CLAP.

/usr/lib/clap just like /usr/lib/vst3 etc

The resources install directory is "Surge XT". The CMake has an install target which will do the right thing but I have no idea what guix expects.

Ashvith10 commented 3 months ago

@baconpaul Thank you for sharing about the difference between Surge and Surge-XT. I'll make sure to create a separate package variant for them.

Apologies about the CLAP question - since then, I've learnt that there's not just Qtractor, but also Zrythm and Anklang. And as you've pointed out, I've created a CLAP folder in the lib directory inside the output, but it may require inputs, for which I'll have to ask a experienced Guix maintainer.

What Guix expects is that all the build files go inside the store directory:

$ tree /gnu/store/ndywg8sdjiizy7pl2shl6b52i5cp973n-surge-xt-1.3.2/ -L 3
/gnu/store/ndywg8sdjiizy7pl2shl6b52i5cp973n-surge-xt-1.3.2/
├── bin
│   ├── Surge XT
│   └── Surge XT Effects
├── etc
│   └── ld.so.cache
├── lib
│   ├── clap
│   │   ├── Surge XT.clap
│   │   └── Surge XT Effects.clap
│   ├── lv2
│   │   ├── Surge XT Effects.lv2
│   │   └── Surge XT.lv2
│   └── vst3
│       ├── Surge XT Effects.vst3
│       └── Surge XT.vst3
└── share
    ├── doc
    │   └── surge-xt-1.3.2
    └── Surge
        ├── fx_presets
        ├── modulator_presets
        ├── patches_3rdparty
        ├── patches_factory
        ├── skins
        ├── tuning_library
        ├── wavetables
        ├── wavetables_3rdparty
        └── WHERE TO PLACE USER DATA.txt

23 directories, 6 files

I am close to the result, however, there's some patches to be added, as Surge isn't able to detect patches installed inside the stores. The standalone binaries also seems to be failing for some reason I can't figure out:

ashvith@glory-lily ~/Desktop/guix [env]$ ./pre-inst-env guix shell surge-xt zrythm ardour
;;; note: source file /home/ashvith/Desktop/guix/gnu/packages/music.scm
;;;       newer than compiled /home/ashvith/Desktop/guix/gnu/packages/music.go
;;; note: source file /home/ashvith/Desktop/guix/gnu/packages/music.scm
;;;       newer than compiled /home/ashvith/Desktop/guix/gnu/packages/music.go
;;; note: source file /home/ashvith/Desktop/guix/gnu/packages/music.scm
;;;       newer than compiled /run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/music.go
;;; note: source file /home/ashvith/Desktop/guix/gnu/packages/music.scm
;;;       newer than compiled /run/current-system/profile/lib/guile/3.0/site-ccache/gnu/packages/music.go

ashvith@glory-lily ~/Desktop/guix [env]$ Surge\ XT
Surge Error [Path Error]
Your user directory '/home/ashvith/Surge XT' is not a directory.
Segmentation fault

ashvith@glory-lily ~/Desktop/guix [env]$ Surge\ XT\ Effects
Surge Error [Path Error]
Your user directory '/home/ashvith/Surge XT' is not a directory.
Segmentation fault
baconpaul commented 3 months ago

Right so a few thoughts

  1. if you set the cmake prefix to that gnu store guid path surge will compile it in and search it.

  2. we did a lot of work on windows to deal with non existent user directories but haven’t ported it to Linux. But we follow the xdg spec to find your writable directory. Are you set up for that? If not you’ll probably have to sling some code in surge storage

Ashvith10 commented 3 months ago

@baconpaul hi, it looks like the standalone version is still not working. All three plugin formats work fine - but as I've said before, none of them can find the patches in the stores. For now, I want to focus on fixing the standalone version. Here's the backtrace for gdb:

$ gdb Surge\ XT -q
Reading symbols from Surge XT...
(No debugging symbols found in Surge XT)
(gdb) run
Starting program: /gnu/store/n5c74ccxq8j7c0sb6ys2pzglpdqfr5vh-profile/bin/Surge XT 
warning: File "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
    add-auto-load-safe-path /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
To completely disable this security protection add
    set auto-load safe-path /
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
    info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libthread_db.so.1".
[New Thread 0x7ffff5e00640 (LWP 13930)]
[New Thread 0x7ffff5400640 (LWP 13931)]
[New Thread 0x7ffff4a00640 (LWP 13932)]
[Thread 0x7ffff4a00640 (LWP 13932) exited]
[Thread 0x7ffff5400640 (LWP 13931) exited]
[Thread 0x7ffff5e00640 (LWP 13930) exited]
[New Thread 0x7ffff5e00640 (LWP 13936)]
[New Thread 0x7ffff5400640 (LWP 13937)]
[New Thread 0x7ffff4a00640 (LWP 13938)]
[Thread 0x7ffff4a00640 (LWP 13938) exited]
[Thread 0x7ffff5400640 (LWP 13937) exited]
[Thread 0x7ffff5e00640 (LWP 13936) exited]
[New Thread 0x7ffff5e00640 (LWP 13939)]
[New Thread 0x7ffff5400640 (LWP 13940)]
[New Thread 0x7ffff4a00640 (LWP 13941)]
[Thread 0x7ffff4a00640 (LWP 13941) exited]
[Thread 0x7ffff5400640 (LWP 13940) exited]
[Thread 0x7ffff5e00640 (LWP 13939) exited]
[New Thread 0x7ffff5e00640 (LWP 13942)]
[New Thread 0x7ffff5400640 (LWP 13943)]
[New Thread 0x7ffff4a00640 (LWP 13944)]
[Thread 0x7ffff4a00640 (LWP 13944) exited]
[Thread 0x7ffff5400640 (LWP 13943) exited]
[Thread 0x7ffff5e00640 (LWP 13942) exited]
[New Thread 0x7ffff5e00640 (LWP 13945)]
[New Thread 0x7ffff5400640 (LWP 13946)]
[New Thread 0x7ffff4a00640 (LWP 13947)]
[New Thread 0x7fffefe00640 (LWP 13948)]
[New Thread 0x7fffef400640 (LWP 13949)]
[New Thread 0x7fffeea00640 (LWP 13950)]
[New Thread 0x7fffee000640 (LWP 13951)]

Thread 1 "Surge XT" received signal SIGSEGV, Segmentation fault.
0x00000000004b3866 in ?? ()
(gdb) backtrace 
#0  0x00000000004b3866 in ?? ()
#1  0x00000000004b69f6 in ?? ()
#2  0x00000000004b7c1b in ?? ()
#3  0x00000000006cbf1e in ?? ()
#4  0x000000000046eecd in ?? ()
#5  0x00007ffff782d1f7 in __libc_start_call_main () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#6  0x00007ffff782d2ac in __libc_start_main_impl () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#7  0x00000000004b15a1 in ?? ()
(gdb) 
baconpaul commented 3 months ago

Well that backtrace shows nothing of course. I think you’ll need to do a debug build to get a correct trace.

The standalone should start without resources but I don’t have much advice other than “hmm yeah it looks like you need to debug” and “with paths like thst I bet you will learn to love the surge storage constructor when debugging”

but try a debug build and share a stack with symbols and I may have a better idea.

Ashvith10 commented 3 months ago

@baconpaul is this better?

$ gdb Surge\ XT -q
Reading symbols from Surge XT...
(No debugging symbols found in Surge XT)
(gdb) run
Starting program: /gnu/store/43s851lijxlrrvf60xl74lrfv2z2cgw2-profile/bin/Surge XT 
warning: File "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
    add-auto-load-safe-path /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
To completely disable this security protection add
    set auto-load safe-path /
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
    info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libthread_db.so.1".
JUCE v7.0.5
JUCE Assertion failure in juce_linux_XWindowSystem.cpp:1730

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff7841487 in kill () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
(gdb) backtrace 
#0  0x00007ffff7841487 in kill () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#1  0x000000000055d7db in ?? ()
#2  0x00000000005d4f33 in ?? ()
#3  0x00000000005d5055 in ?? ()
#4  0x00000000005462a0 in ?? ()
#5  0x00000000004b78fc in ?? ()
#6  0x000000000054da75 in ?? ()
#7  0x0000000000549d7e in ?? ()
#8  0x00000000005486a4 in ?? ()
#9  0x000000000042b5be in ?? ()
#10 0x000000000042d858 in ?? ()
#11 0x000000000042d915 in ?? ()
#12 0x00000000007aaaf1 in ?? ()
#13 0x0000000000552028 in ?? ()
#14 0x00000000007aa9a7 in ?? ()
#15 0x00000000007aa8de in ?? ()
#16 0x0000000000426bc5 in ?? ()
#17 0x00007ffff782d1f7 in __libc_start_call_main () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#18 0x00007ffff782d2ac in __libc_start_main_impl () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#19 0x0000000000426a91 in ?? ()
(gdb) 
mkruselj commented 3 months ago

No, this is still without symbols.

baconpaul commented 3 months ago

but this line

JUCE Assertion failure in juce_linux_XWindowSystem.cpp:1730

is interesting and means you have a (stripped) debug build somehow. (Does guix strip things automatically?)

That assertion is

    jassert (windowH != 0);

where winwodH is the height. Maybe stop the debugger there and see the call stack? Is your window manager not allowing a sized window to be created?

Ashvith10 commented 3 months ago

@baconpaul @mkruselj I realized that the binaries are stripped by default - it is one of the many build phases in Guix. Just a question - if I add the flag "-DCMAKE_BUILD_TYPE=Release", would that still strip binaries?

Ashvith10 commented 3 months ago

I think the symbols are loaded now, right?

$ gdb Surge\ XT -q
Reading symbols from Surge XT...
(gdb) run
Starting program: /gnu/store/215sycmn9hv873n2gac1559jdglzpi36-profile/bin/Surge XT 
warning: File "/gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
    add-auto-load-safe-path /gnu/store/6ncav55lbk5kqvwwflrzcr41hp5jbq0c-gcc-11.3.0-lib/lib/libstdc++.so.6.0.29-gdb.py
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
To completely disable this security protection add
    set auto-load safe-path /
line to your configuration file "/home/ashvith/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
    info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libthread_db.so.1".
[Detaching after fork from child process 5680]
[New Thread 0x7ffff5e00640 (LWP 5681)]
[New Thread 0x7ffff5400640 (LWP 5682)]
[New Thread 0x7ffff4a00640 (LWP 5683)]
[Thread 0x7ffff4a00640 (LWP 5683) exited]
[Thread 0x7ffff5400640 (LWP 5682) exited]
[Thread 0x7ffff5e00640 (LWP 5681) exited]
[Detaching after fork from child process 5684]
[New Thread 0x7ffff5e00640 (LWP 5685)]
[New Thread 0x7ffff5400640 (LWP 5686)]
[New Thread 0x7ffff4a00640 (LWP 5687)]
[Thread 0x7ffff4a00640 (LWP 5687) exited]
[Thread 0x7ffff5400640 (LWP 5686) exited]
[Thread 0x7ffff5e00640 (LWP 5685) exited]
[Detaching after fork from child process 5688]
[New Thread 0x7ffff5e00640 (LWP 5689)]
[New Thread 0x7ffff5400640 (LWP 5690)]
[New Thread 0x7ffff4a00640 (LWP 5691)]
[Thread 0x7ffff4a00640 (LWP 5691) exited]
[Thread 0x7ffff5400640 (LWP 5690) exited]
[Thread 0x7ffff5e00640 (LWP 5689) exited]
[Detaching after fork from child process 5692]
[New Thread 0x7ffff5e00640 (LWP 5693)]
[New Thread 0x7ffff5400640 (LWP 5694)]
[New Thread 0x7ffff4a00640 (LWP 5695)]
[Thread 0x7ffff4a00640 (LWP 5695) exited]
[Thread 0x7ffff5400640 (LWP 5694) exited]
[Thread 0x7ffff5e00640 (LWP 5693) exited]
[New Thread 0x7ffff5e00640 (LWP 5696)]

Thread 1 "Surge XT" received signal SIGSEGV, Segmentation fault.
juce::StandaloneFilterWindow::StandaloneFilterWindow(juce::String const&, juce::Colour, juce::PropertySet*, bool, juce::String const&, juce::AudioDeviceManager::AudioDeviceSetup const*, juce::Array<juce::StandalonePluginHolder::PluginInOuts, juce::DummyCriticalSection, 0> const&, bool)::{lambda()#1}::operator()() const (
    __closure=__closure@entry=0x7fffffffe298)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h:766
warning: 766    /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h: No such file or directory
(gdb) bt
#0  juce::StandaloneFilterWindow::StandaloneFilterWindow(juce::String const&, juce::Colour, juce::PropertySet*, bool, juce::String const&, juce::AudioDeviceManager::AudioDeviceSetup const*, juce::Array<juce::StandalonePluginHolder::PluginInOuts, juce::DummyCriticalSection, 0> const&, bool)::{lambda()#1}::operator()() const (
    __closure=__closure@entry=0x7fffffffe298)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h:766
#1  0x00000000004b69f6 in juce::StandaloneFilterWindow::StandaloneFilterWindow (this=0x317a5b0, title=..., backgroundColour=..., settingsToUse=0x317a0d0, 
    takeOwnershipOfSettings=<optimized out>, preferredDefaultDeviceName=..., preferredSetupOptions=0x0, constrainToConfiguration=..., autoOpenMidiDevices=false)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h:740
#2  0x00000000004b7c1b in juce::StandaloneFilterApp::createWindow (this=0x3178dc0)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_core/memory/juce_HeapBlock.h:100
#3  juce::StandaloneFilterApp::initialise (this=0x3178dc0)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterApp.cpp:96
#4  0x00000000006cbf1e in juce::JUCEApplicationBase::initialiseApp (this=0x3178dc0)
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_events/messages/juce_ApplicationBase.cpp:300
#5  0x000000000046eecd in juce::JUCEApplicationBase::main ()
    at /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_events/messages/juce_ApplicationBase.cpp:259
#6  0x00007ffff782d1f7 in __libc_start_call_main () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#7  0x00007ffff782d2ac in __libc_start_main_impl () from /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libc.so.6
#8  0x00000000004b15a1 in _start ()
(gdb) 
baconpaul commented 3 months ago

Yes

that points to an inability to create a window in juce code

are you running an x display? Does xclock work in the session where you are running the test? Are you running a peculiar window manager or a weirdly configured Wayland plus x or some such?

Ashvith10 commented 3 months ago

xclock works fine for me. I'm on default GNOME in Wayland.

baconpaul commented 3 months ago

Right.

Well. Hmm. I'm sorry the only answer I can give you is "Something is screwed up in the window creating pipeline" and "its not screwed up on ubuntu 22" and "at least you have all the source!"

Wish I could do better but I'm not quite sure what to suggest other than step it in the debugger, read the code, and see where it goes wrong. That's a bit of the codebase I've never looked at since this is the first time it's not worked for someone and it comes from juce.

Any odd versions of xcb or some such in your build maybe? That's the only other thing I can think of.

Ashvith10 commented 3 months ago

@baconpaul what do you think about this line:

warning: 766    /tmp/guix-build-surge-xt-1.3.2.drv-0/source/libs/JUCE/modules/juce_audio_plugin_client/Standalone/juce_StandaloneFilterWindow.h: No such file or directory

Is this problematic?

baconpaul commented 3 months ago

If it was true I think the system wouldn’t compile but need more context probably

mkruselj commented 3 months ago

Since there's nothing we can do about this issue, I am going to close it. Feel free to continue the discussion, if necessary, though.