| 22 Jan 2024 |
 Benedikt Ritter (britter) | Hat von euch schon mal was mit JUCE gemacht? Ich versuche gerade Ultraschall Soundboard zu packagen bekomme aber jede Menge fehler beim linken, dass Sachen von Juce nicht gefunden werden. Code: https://github.com/britter/nix-configuration/blob/bene/ultraschall/packages/ultraschall-soundboard/default.nix kann man mit nix build .#ultraschall-soundboard bauen (ist auf dem bene/ultraschall branch).
| 10:12:23 |
| Benedikt Ritter (britter) | In reply to @britter:yatrix.org
Hat von euch schon mal was mit JUCE gemacht? Ich versuche gerade Ultraschall Soundboard zu packagen bekomme aber jede Menge fehler beim linken, dass Sachen von Juce nicht gefunden werden. Code: https://github.com/britter/nix-configuration/blob/bene/ultraschall/packages/ultraschall-soundboard/default.nix kann man mit nix build .#ultraschall-soundboard bauen (ist auf dem bene/ultraschall branch).
Muesste es nicht eigentlich reichen JUCE als buildInput zu deklarieren, damit es beim Linker ankommt? | 10:12:57 |
| 23 Jan 2024 |
 Moritz Sanft | Theoretisch ja. Bei einem Blick in Nixpkgs machen Leute, die andere Audio-Anwendungen packagen aber auch ziemlich viel foo damit: https://github.com/search?q=repo%3ANixOS%2Fnixpkgs%20juce&type=code | 09:19:03 |
| Moritz Sanft | die libX... musst du vermutlich einmal nach runtimeDependencies spiegeln oder über env.NIX_LDFLAGS als library search paths includen, damit dlopen funktioniert. Das löst allerdings noch nicht das Linking-Problem | 09:21:00 |
| Benedikt Ritter (britter) | Danke fuer deine Antwort, Moritz! Was bedeutet es denn eigentlich einen Fehler beim Linken zu haben? Der Compiler konnte den Code kompilieren, aber dann beim Linken fehlt die Library ploetzlich? Das verstehe ich nicht :-/ | 15:16:21 |
| Moritz Sanft | Genau. Der Compiler baut einzelne Objektdateien, und der Linker versucht dann, sie anhand von Symbolen zusammenzuhängen. Außerdem löst der Linker auch Referenzen zu Libraries auf. Das kann dann beim Compilen selbst passieren (statisch) oder zur Laufzeit (dynamisch). In ersterem Fall baut dir der Linker dann eine Binary, in der alle Symbole bereits aufgelöst sind. Beim dynamischen Linking ist der Loader zur Runtime dafür verantwortlich, die richtigen Libraries in den Arbeitsspeicher des Prozesses zu laden. | 15:25:28 |
| Moritz Sanft | Was man noch überprüfen könnte: Ist das JUCE-Package, dass du importierst, auf der Version, die Ultraschall-Soundboard required? Falls nicht könnte es natürlich sein, dass bestimmte Symbole noch nicht oder nicht mehr in JUCE definiert sind. | 15:37:54 |
| Benedikt Ritter (britter) | Das werde ich mal nachsehen. Aber es kommen so viele Fehler, dass ich glaube, dass JUCE garnicht richtig gefunden wird. | 15:38:28 |
| Moritz Sanft | Hier noch ein Paar weitere Infos zum Compilen und Linken (spezifisch für C, aber trifft eigentlich auch auf alles andere zu, was compiled): https://www.cprogramming.com/compilingandlinking.html | 15:39:04 |
| Benedikt Ritter (britter) | Leider ist das etwas schwierig genau rauszufinden welche Version verwendet wird, weil der Build von Ultraschall einfach immer nur die Source Repos cloned, ohne dass ein commit hash angegeben ist 🙄️ | 15:39:15 |
| Moritz Sanft | Ah. Es wäre am besten, wenn man die Dependencies alle über Nix zur Verfügung stellen würde | 15:40:00 |
| Benedikt Ritter (britter) | Das hat man davon, wenn man Wirtschaftsinformatik studiert und es im ersten Semester direkt mit Java losgeht 🙂️ Bin auch bei keinem Job mal mit was anderem in Beruehrung gekommen. Java hat immer alle Rechnungen bezahlt 😁️ | 15:40:22 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Ah. Es wäre am besten, wenn man die Dependencies alle über Nix zur Verfügung stellen würde Ja, da arbeite ich ja dran... Ich hab in meiner Derivation das Repo gefetchet und dann juce als buildInput uebergeben. | 15:40:54 |
| Moritz Sanft | Also im Bachelor habe ich auch nur Python und Java gemacht -- Leider. Im Master wurde man dann ins kalte Wasser geschmissen. | 15:41:29 |
| Moritz Sanft | Also Ultraschall-Soundboard hat einfach einmal den kompletten JUCE-Source in ihrem Repo, oder? | 15:43:16 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Also Ultraschall-Soundboard hat einfach einmal den kompletten JUCE-Source in ihrem Repo, oder? Ja! https://github.com/Ultraschall/ultraschall-soundboard/tree/main/JUCE Dann macht es vermutlich keinen Sinn, dass ich das noch mal als buildInput uebergebe 🤔️ | 15:46:41 |
| Moritz Sanft | Es wäre vermutlich sinnvoll, das als Buildinput zu übergeben und dann Ultraschall-Soundboard zu sagen, dass die nicht dden JUCE-Source aus ihrem Repo bauen sollen (vermutlich als Patch in der CMakelists.txt). Kenne mich aber selbst leider überhaupt nicht mit CMake aus. Da hast du dir auf jeden Fall eine harte Nuss zum packagen ausgesucht. :D | 15:47:56 |
| Moritz Sanft | add_subdirectory("./JUCE" JUCE) ggf. könnte man das hier so patchen, dass der JUCE-Source aus nixpkgs genutzt wird. | 15:49:17 |
| Moritz Sanft | Sonst würde ich JUCE aus den Buildinputs rausnehmen. Das dürfte auch funktionieren. | 15:49:35 |
| Benedikt Ritter (britter) | Ach, das waere nicht das erste Problem, das ich hier loesen muss. Ich musste ja schon die ganze StudioLink Geschichte packagen. Das habe ich nach vier Wochen letztens endlich fertig gehabt. Da dachte ich, jetzt wuerde es einfach werden. Naja, dann kam halt Soundboard :) | 15:53:24 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
add_subdirectory("./JUCE" JUCE) ggf. könnte man das hier so patchen, dass der JUCE-Source aus nixpkgs genutzt wird. Aber die sourcen sind ja nicht in nixpkgs, nur der build output, oder? | 15:53:56 |
| Moritz Sanft | Genau, aber du könntest auch den Source mit nixpkgs fetchen und den dann reingeben (z.B. fetchFromGithub). Dürfte aber nichts ändern im Vergleich zu einfach JUCE als BuildInput rausnehmen. Hilft dir nur später bei Reproducibility | 15:55:04 |
|  blipp joined the room. | 21:58:49 |
| 2 Feb 2024 |
| Benedikt Ritter (britter) | In reply to @msanft:matrix.org
Genau, aber du könntest auch den Source mit nixpkgs fetchen und den dann reingeben (z.B. fetchFromGithub). Dürfte aber nichts ändern im Vergleich zu einfach JUCE als BuildInput rausnehmen. Hilft dir nur später bei Reproducibility Hab gar nicht mehr geantwortet. Bin noch nicht dazu gekommen weiter zu machen. Ich glaube hinsichtlich Reproducibility waere es besser das JUCE zu nehmen, welches im Repo ist. Dann passt es immer zum Code. Vielleicht muss ich den buildInput wieder rausnehmen und dann die richtigen make und ld flags setzen, damit es verwendet wird? | 20:01:15 |
| Benedikt Ritter (britter) | Mal ne andere Frage: Derivations laufen ja in einer Art Sandbox. Sind aus der Sandbox heraus http requests moeglich? Ich hab da eine Derivation, welche Gradle aufruft. Aber der Gradle Build kann seine Plugins nicht aufloesen. Wenn ich das Repo clone und den Build dort ausfuehre funktioniert es :-/ | 20:02:51 |
| Benedikt Ritter (britter) | nix build github:britter/nix-configuration/bene/issues/4#groovy-language-server
| 20:03:10 |
 CRTified | In reply to @britter:yatrix.org
Mal ne andere Frage: Derivations laufen ja in einer Art Sandbox. Sind aus der Sandbox heraus http requests moeglich? Ich hab da eine Derivation, welche Gradle aufruft. Aber der Gradle Build kann seine Plugins nicht aufloesen. Wenn ich das Repo clone und den Build dort ausfuehre funktioniert es :-/ Nein, man kann die sandbox aber deaktivieren | 20:24:21 |
| CRTified | Ist aber nicht sinnvoll normalerweise | 20:25:57 |
| Benedikt Ritter (britter) | Wie macht man es denn, wenn man in der derivation ein tool nutzen will, welches http requests machen muss? | 20:32:28 |
| CRTified | Fixed output derivations sind da iirc die Antwort | 20:38:07 |
