Rpmbuild für Zynaddsubfx: %cmake_build-Fehler

[dimke]

Hallo zusammen,
versuche seit Stunden, unter MGA7/x64 ein neueres Zynaddsubfx (3.0.6) aus Mageia 9 / Cauldron zu bauen.
Ähnlich wie bei https://forums.mageia.org/de/viewtopic.php?f=10&t=3685
steigt auch bei mir rpmbuild -ba jedesmal aus mit

Code: Alles auswählen

%cmake_build
/var/tmp/[...] fg: no job control

- Rpmbuild von Zyn.3.0.4 aus dem MGA7/x64-Repo läuft problemlos durch.
- Die Spec-Datei aus 3.0.4 anzupassen und nur den Quell-Tarball auszutauschen, schlug ebenfalls fehl. Vermutlich wird im Quelltext auf etwas referenziert, das hier nicht existiert.

Ich hatte dann versucht, die Pakete cmake und cmake-rpm-macros ebenfalls aus Cauldron neu zu bauen, was aber mit dem selben Fehler endete.

Kann mir bitte jemand sagen, welche Pakete ich per "Backport" zuvor aktualisieren / neu bauen und installieren sollte, damit sich Zynaddsubfx schliesslich bauen lässt?

P.S. Rpmbuild-Vorgang läuft zur besseren Trennung in einer Virtualbox-Umgebung, diese ist aber weitgehend mit dem Host identisch.

Danke und Gruss,
Markus

[doktor5000]

Wie auch im anderen Thread beschrieben, du müsstest nur das %cmake_build Makro definieren, so wie es in Cauldron definiert ist.
Oder das was beim Makro gemacht wird anstelle %cmake_build einfügen.
rpmbuild muss übrigens nicht in einer extra VM laufen, solange man es nicht als root startet.

[dimke]

Hallo, danke,

Wie auch im anderen Thread beschrieben, du müsstest nur das %cmake_build Makro definieren, so wie es in Cauldron definiert ist.

Im Paket cmake-rpm-macros-9-9.mga9.src.rpm / Cauldron ist eine Datei, macros.cmake.
Dort ist definiert

Code: Alles auswählen

%cmake_build \
    %__cmake --build "%{_vpath_builddir}" %{?_smp_mflags} --verbose

Die wollte ich dann im MGA7/x64 in die Datei /etc/rpm/macros.d/cmake.macros einfügen, oder besser noch, das Paket cmake-rpm-macros-3.14.3-1.mga7 mit der Information zusammen neu bauen.

Testweise habe ich dann aber vorher noch genau die Ersetzung

Oder das was beim Makro gemacht wird anstelle %cmake_build einfügen.

in der Spec-Datei gemacht:

Code: Alles auswählen

%__cmake --build "%{_vpath_builddir}" %{?_smp_mflags} --verbose
# %cmake_build

Jetzt steigt rpmbuild -ba zynaddsubfx.spec aber aus mit

Code: Alles auswählen

+ /usr/bin/cmake --build '%{_vpath_builddir}' --verbose
Error: /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/%{_vpath_builddir} is not a directory
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.uCC2v5 (%build)

Fehler beim Bauen des RPM:
    Fehler-Status beim Beenden von /var/tmp/rpm-tmp.uCC2v5 (%build)

Der kommt schon mit der _vpath_builddir-Variablen nicht klar.
Habe ich da irgendwas übersehen?

Danke und viele Grüsse,
Markus

P.S.

rpmbuild muss übrigens nicht in einer extra VM laufen, solange man es nicht als root startet.

Bringt aber auch Vorteile:
- Bauen für unterschiedliche Zielplattformen einfach möglich
- installiert man das rpm dann auf dem Host-Rechner, ist das wie ein Fremdsystem, und man sieht sofort, ob das rpm überall lauffähig ist
- hat man die VM mit Installationen, Bibliotheken etc. irgendwann überfrachtet, dann wirft man die weg und ersetzt sie durch eine saubere Rücksicherung

[sturmvogel]

- Bauen für unterschiedliche Zielplattformen einfach möglich
- installiert man das rpm dann auf dem Host-Rechner, ist das wie ein Fremdsystem, und man sieht sofort, ob das rpm überall lauffähig ist
- hat man die VM mit Installationen, Bibliotheken etc. irgendwann überfrachtet, dann wirft man die weg und ersetzt sie durch eine saubere Rücksicherung

Geht auch anders...
https://wiki.mageia.org/en/Verwenden_von_Mock-de
und
https://wiki.mageia.org/en/Packagers_chroot

[doktor5000]

Testweise habe ich dann aber vorher noch genau die Ersetzung in der Spec-Datei gemacht:

Code: Alles auswählen

%__cmake --build "%{_vpath_builddir}" %{?_smp_mflags} --verbose
# %cmake_build

Jetzt steigt rpmbuild -ba zynaddsubfx.spec aber aus mit

Code: Alles auswählen

+ /usr/bin/cmake --build '%{_vpath_builddir}' --verbose
Error: /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/%{_vpath_builddir} is not a directory
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.uCC2v5 (%build)

Fehler beim Bauen des RPM:
    Fehler-Status beim Beenden von /var/tmp/rpm-tmp.uCC2v5 (%build)

Der kommt schon mit der _vpath_builddir-Variablen nicht klar.
Habe ich da irgendwas übersehen?

%{_vpath_builddir} ist auch ein Makro, keine Variable. Auch da musst du schauen wie die belegt ist. Einzelne Makros kann man so evaluieren:

Code: Alles auswählen

rpm -E '%{_vpath_builddir}'

Oder mittels

Code: Alles auswählen

rpm --showrc | grep -i vpath_builddir

für dein Beispiel schauen wo das herkommt und wie es definiert wird.

Hier sieht es aber eher so aus hier /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/%{_vpath_builddir} als Verzeichnis erwartet wird, und da aber kein solches Verzeichnis existiert. Wird vermutlich vorher irgendwo in %prep oder %build angelegt.

[dimke]

Hallo zurück,
hab heute eine Testinstallation (VirtualBox VM) mit MGA9 Cauldron x64 aufgesetzt.
Komischerweise wird dort jetzt so aufgelöst:

Code: Alles auswählen

rpm -E %cmake_build
/usr/bin/cmake --build "build" -j1 --verbose

Das "build" scheint auch zu viel und verweist auf ./build/build/, sodass ich obige Zeile in

Code: Alles auswählen

/usr/bin/cmake --build "." -j1 --verbose

geändert habe.

Jetzt läuft cmake bis 87% durch, aber ab da hagelt es Fehler wie
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_filename_ext(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::uncache()'
Vermutlich ebenfalls durch cmake getriggert.

Weiss jemand, wo die Prozentangabe des Build-Fortschrittes herkommt?
Wie und durch was wird die bestimmt?

Ich versuche gerade, die Stelle zu finden, wo die Fehler auftreten.

Danke und Gruss,
Markus

[sturmvogel]

Mal eine andere Frage. Klar kannst du jetzt viel bezüglich Programmkompilierung lernen... Aber warum upgradest du deine Maschine nicht zu Mageia 8? Mageia 7 ist EOL seit 2021 und somit als unsicher zu betrachten da es keinerlei Updates mehr erhält...
Sogar Mageia 9 "steht kurz vor der Tür".

[dimke]

Moin,
dass es schon Version 9 gibt, habe ich mitbekommen...
Beispiel aus der Praxis:
Polkit hatte einen ausgesprochen gefährlichen Bug. Das war vor einem Jahr.
Ich sofort Bugreport geschrieben, und? Was kam zurück?
"Nee, Version 7 ist end of life", und "perhaps you want to roll forward to Vers.8" und bla.
Ich hatte aber keine Zeit, die nächste Version zu installieren und alle im Repo nicht erhältlichen Pakete neu zu übersetzen.

Da war mir klar, ich bin allein im Wald.

Ich ins 8er-Repo reingeschaut, und, bingo -- ein Bugfix!
Ich alle nötigen Pakete neu erstellt und installiert, von github den Exploit nochmal drüberlaufen lassen, und:
Die Sicherheitslücke war weg!

Erfahrung und Wissen schaden nie. Punkt.
Und neuer Absatz.

Mir geht es schon lange nicht mehr um das genannte Paket. Das steht nur noch stellvertretend für widerborstige Pakete, die sich nur mit Tricks rückportieren lassen.

Wäre also nett, wenn jemand wüsste, wie die Prozentangabe herkommt, und wie man z.B. "87%" im Quelltext findet.

Viele Grüsse,
Markus

[doktor5000]

Dir sind die Sicherheitslücken wichtig, aber du hast nicht genug Zeit auf die nächste Version zu aktualisieren? Da solltest du dich für eins entscheiden.
Davon abgesehen, ein Upgrade dauert normalerweise nicht viel länger als eine Stunde mit etwas Vorbereitung.
Man könnte auch jederzeit neuinstallieren (15 min.) und aus einem aktuellen Backup die relevanten Daten wieder hinlegen. Dauert mit etwas Übung auch nur knapp über eine Stunde.

Die Prozentangabe bei cmake kommt vom darunterliegenden Buildsystem, also normalerweise automake. Die findet sich nirgends im Quelltext und wird nur geschätzt/berechnet anhand der Anzahl der make-targets.
Was genau suchst du denn konkret bei 87% ?

[dimke]

Hallo,

Dir sind die Sicherheitslücken wichtig, aber du hast nicht genug Zeit auf die nächste Version zu aktualisieren? Da solltest du dich für eins entscheiden.
Davon abgesehen, ein Upgrade dauert normalerweise nicht viel länger als eine Stunde mit etwas Vorbereitung.
Man könnte auch jederzeit neuinstallieren (15 min.) und aus einem aktuellen Backup die relevanten Daten wieder hinlegen. Dauert mit etwas Übung auch nur knapp über eine Stunde.

da ist noch ein anderer Aspekt:
In dem Moment, wenn ein OS-Release als "stable" freigegeben wird, ist schon alles veraltet und es werden (fast) nur noch Sicherheits-Bugfixes eingestellt.
Will man beides, stablies OS UND aktuelle Pakete, dann bleibt nichts anderes übrig, als diese Pakete aus dem (jeweiligen) Cauldron-Repo rückzuportieren.
Gruss,
Markus

[dimke]

Hallo,

Die Prozentangabe bei cmake kommt vom darunterliegenden Buildsystem, also normalerweise automake. Die findet sich nirgends im Quelltext und wird nur geschätzt/berechnet anhand der Anzahl der make-targets.
Was genau suchst du denn konkret bei 87% ?

bei rpmbuild unter MGA7 ist bei "87%" die letzte Ausgabe, auch da immer wechselweise
Building Komponente x
...
Linking Komponente x
...
ab der dann ein Linker-Fehler nach dem anderen kommt.
Auch da läuft rpmbuild bei MGA9 aber durch.

MGA7:

Code: Alles auswählen

[ 87%] Building CXX object src/Tests/CMakeFiles/ins-test.dir/InstrumentStats.cpp.o
cd /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/src/Tests && /usr/bin/c++  -DALSA=1 -DASM_F2I_YES -DHAVE_ASYNC=1 -DHAVE_CPP_STD_COMPLEX=1 -DHAVE_SCHEDULER=1 -DJACK=1 -DNTK_GUI -DOSS=1 -DPORTAUDIO=1 -DSNDIO=1 -DSOURCE_DIR=\"/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/src/Tests\" -DUSE_NSM=1 -DVERSION=\"\" -I/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/src/UI -I/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/src/UI -I/usr/include/libdrm -I/usr/include/libxml2 -I/usr/include/uuid -I/usr/include/libpng16 -I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/lib64/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/include/cairo -I/usr/include/ntk -I/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/rtosc/include -I/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/src -I/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/src  -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables -std=c++11 -Wno-unused-parameter -O3 -ffast-math -fomit-frame-pointer  -msse -msse2 -mfpmath=sse   -Wall -Wextra -fPIC -o CMakeFiles/ins-test.dir/InstrumentStats.cpp.o -c /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/src/Tests/InstrumentStats.cpp
[ 87%] Linking CXX executable ins-test
cd /home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build/src/Tests && /usr/bin/cmake -E cmake_link_script CMakeFiles/ins-test.dir/link.txt --verbose=1
/usr/bin/c++  -O2 -g -pipe -Wformat -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables -std=c++11 -Wno-unused-parameter -O3 -ffast-math -fomit-frame-pointer  -msse -msse2 -mfpmath=sse  -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags -rdynamic CMakeFiles/ins-test.dir/InstrumentStats.cpp.o  -o ins-test ../libzynaddsubfx_core.a ../UI/libzynaddsubfx_gui.a -lntk -lcairo -lntk_images -lntk -lcairo -lGL -lGLU -lSM -lICE -lX11 -lXext -lXpm -lz -lfftw3f -lmxml -lpthread -lpthread -Wl,--no-as-needed -lpthread -lrt ../../rtosc/librtosc-cpp.a ../../rtosc/librtosc.a -lntk_images
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_filename_ext(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::uncache()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Window::size_range_()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Input::Fl_Input(int, int, int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Image::~Fl_Image()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl::warning'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_File_Icon::add(short)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::~Fl_Pixmap()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Widget::deactivate()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Shared_Image::Fl_Shared_Image(char const*, Fl_Image*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_numericsort'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `typeinfo for Fl_RGB_Image'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::desaturate()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_filename_isdir(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::draw(int, int, int, int, int, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Button::Fl_Button(int, int, int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Window::show(int, char**)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::set_data(char const* const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::desaturate()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_strlcpy'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `vtable for Fl_Box'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Group::current()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_color_average(unsigned int, unsigned int, float)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::label(Fl_Widget*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Shared_Image::release()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_fopen'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::label(Fl_Widget*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::load(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::label(Fl_Menu_Item*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Widget::Fl_Widget(int, int, int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::topline(int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::color_average(unsigned int, float)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `typeinfo for Fl_Pixmap'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Shared_Image::get(char const*, int, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `vtable for Fl_Double_Window'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl::error'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Group::end()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Shared_Image::add()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Window::Fl_Window(int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::value(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::copy(int, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::copy(int, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::~Fl_RGB_Image()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::format()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Widget::tooltip(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Group::Fl_Group(int, int, int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::topline(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::draw(int, int, int, int, int, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Window::label(char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `fl_filename_list(char const*, dirent***, int (*)(dirent**, dirent**))'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::Fl_Help_View(int, int, int, int, char const*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Shared_Image::add_handler(Fl_Image* (*)(char const*, unsigned char*, int))'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Widget::activate()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `vtable for Fl_Pixmap'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_File_Icon::Fl_File_Icon(char const*, int, int, short*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Help_View::find(char const*, int)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::label(Fl_Menu_Item*)'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::uncache()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_Pixmap::measure()'
/usr/bin/ld: /usr/lib/gcc/x86_64-mageia-linux-gnu/8.4.0/../../../../lib64/libntk_images.so: undefined reference to `Fl_RGB_Image::color_average(unsigned int, float)'
collect2: error: ld returned 1 exit status
gmake[2]: *** [src/Tests/CMakeFiles/ins-test.dir/build.make:98: src/Tests/ins-test] Error 1
gmake[2]: Leaving directory '/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build'
gmake[1]: *** [CMakeFiles/Makefile2:3726: src/Tests/CMakeFiles/ins-test.dir/all] Error 2
gmake[1]: Leaving directory '/home/rpmbuild/rpmbuild/BUILD/zynaddsubfx-3.0.6/build'
gmake: *** [Makefile:144: all] Error 2
Fehler: Fehler-Status beim Beenden von /var/tmp/rpm-tmp.OsgBVT (%build)

Fehler beim Bauen des RPM:
    Fehler-Status beim Beenden von /var/tmp/rpm-tmp.OsgBVT (%build)

Sorry für das ausgedehnte Zitat, aber vielleicht kann jemand da was draus lesen.
Danke und Gruss,
Markus

[dimke]

Hallo,
mir ist gerade noch was aufgefallen. Die Auflösung des %cmake_build-Makros weicht ab.

Das cmake 3.14.3 unter MGA7 will:
cmake --build "." -j1 --verbose
# %cmake_build

Das cmake 3.26.0-rc4 unter MGA9 will das haben:
cmake --build "build" -j1 --verbose
# %cmake_build

In der Spec-Datei steht aber keine geforderte Version, sondern nur "BuildRequires: cmake".

Und in der CMakeLists.txt innerhalb des Tarballs steht was von "cmake_minimum_required(VERSION 3.0)"

Suggeriert, die Version sei egal. Ist sie aber offensichtlich nicht.

Sollte man evtl. cmake inkl. cmake-macros neu bauen?

Danke und Gruss,
Markus

[doktor5000]

Die ganzen "undefined reference to <Shared Library Symbol>" Meldungen sind ein Zeichen für Underlinking. Siehe dazu https://wiki.mageia.org/en/Packaging_problems_and_solutions#undefined_reference_to_.60xxx.27 bzw. https://wiki.mageia.org/en/Underlinking_issues_in_packaging

Und warum das Makro anders auflöst, du hattest doch zuvor geschrieben

Hallo zurück,
hab heute eine Testinstallation (VirtualBox VM) mit MGA9 Cauldron x64 aufgesetzt.
Komischerweise wird dort jetzt so aufgelöst:

Code: Alles auswählen

rpm -E %cmake_build
/usr/bin/cmake --build "build" -j1 --verbose

Das "build" scheint auch zu viel und verweist auf ./build/build/, sodass ich obige Zeile in

Code: Alles auswählen

/usr/bin/cmake --build "." -j1 --verbose

geändert habe.

Die Angabe hinter --build gibt das Verzeichnis an, in dem kompiliert wird. Das sollte normalerweise das Unterverzeichnis "build" sein vom aktuellen Verzeichnis aus gesehen. Wenn du natürlich vorher da schon reinwechselst, dann musst du das natürlich anpassen.

Hat mit dem Underlinking aber überhaupt nichts zu tun.

[dimke]

Die ganzen "undefined reference to <Shared Library Symbol>" Meldungen sind ein Zeichen für Underlinking. Siehe dazu https://wiki.mageia.org/en/Packaging_problems_and_solutions#undefined_reference_to_.60xxx.27 bzw. https://wiki.mageia.org/en/Underlinking_issues_in_packaging

Die Liste der ldd-Meldungen sieht aus, als wäre nur libntk_images.so,
also lib64ntk1 betroffen. Aus der Wikiseite kann ich nicht herauslesen, ob das darauf hindeutet, dass
- das lib64ntk1 rpm fehlerhaft ist, oder
- aktualisiert werden muss
- oder ob es eines Tricks beim cmake-Aufruf bedarf
um das Problem zu lösen.
Auch scheinen auf MGA9 andere Abhängigkeiten definiert zu sein, denn da gibt es (auf meiner Installation) kein Paket mit Namen *ntk*. Zynadd lässt sich aber trotzdem bauen.
Gruss,
Markus

[dimke]

Hallo nochmal,

Auch scheinen auf MGA9 andere Abhängigkeiten definiert zu sein, denn da gibt es (auf meiner Installation) kein Paket mit Namen *ntk*. Zynadd lässt sich aber trotzdem bauen.

auf Verdacht hin habe ich die *ntk*-Pakete entfernt, und, siehe da, cmake lief auch auf MGA7 durch, genau wie auf der MGA9-Installation.
Da kam nur die Meldung, dass NTK nicht da sei. Sonst nichts.
In dem Moment, als dann die "externen" Programme, also Midi-Spliter (1 t) und Controller gebaut werden sollten, kam der gmake mit dem Pfad durcheinander. Den habe ich anpassen müssen, damit es weiterging. Frage dazu:
Unter der Annahme, die Spec-Datei habe folgenden Abschnitt:

Code: Alles auswählen

%description
A real-time software synthesizer for Linux with many features,
including polyphony, multi-timbral and microtonal capabilities.
It includes randomness of some parameters,which makes warm sounds,
like analogue synthesizers. The program has system/insertion effects.

%prep
%setup -q
%autopatch -p1

%build
# It incorrectly detect neon on procs not having it, and decides to build
# for armv7 + neon on armv5tl
%cmake -DNoNeonPlease:BOOL=ON

cmake --build "." -j1 --verbose
# %cmake_build

%make_build -C %{_builddir}/%{name}-%{version}/ExternalPrograms/Spliter
%make_build -C %{_builddir}/%{name}-%{version}/ExternalPrograms/Controller

%install


und der Build-Lauf dauert eine Viertelstunde, um dann beim ersten "%make_build" auszusteigen.
Dann sind die gebauten Dateien doch noch im Build-Verzeichnis.
Gibt es eine Möglichkeit, nach Korrektur an einer bestimmten Stelle, hier das erste Vorkommen von "%make_build" wieder anzusetzen, statt von Null zu beginnen?

Danke und Gruss,
Markus

[dimke]

Hallo,
an der Stelle nochmal danke für die ganzen Infos!
Nachdem meine Rpm-Datei sauber läuft auf MGA7, wundere ich mich nun aber doch ein wenig über die aktuelle Versionsnummer: In der Srpm-Datei steht die originale Quelle drin. Da ist "Stand der Technik" mit Version 3.0.3 angegeben, wir reden hier von 3.0.6 (!).
Es wurden also (inoffiziell) Änderungen eingebracht, die dann aber nicht an Upstream weitergegeben wurden.
Wie das?
Gruss,
Markus

[sturmvogel]

Da du selbst mit Quellpaketen hin und her jonglierst und wild zwischen MGA7/8/9 wechselst, bist du scheinbar durcheinander gekommen. Upstream ist aktuell 3.0.6. Diese Version wird in MGA9 verwendet. Mageia hat überhaupt nichts am Quellcode geändert! In MGA7 wurde 3.0.4 verwendet…

[dimke]

Hallo Sturmvogel,

Da du selbst mit Quellpaketen hin und her jonglierst und wild zwischen MGA7/8/9 wechselst, bist du scheinbar durcheinander gekommen.

Wäre ja plausibel. Geb ich Dir gerne Recht, aber

Upstream ist aktuell 3.0.6.

auf Seite
https://sourceforge.net/projects/zynadd ... t/download
steht unter "latest":
"zynaddsubfx-3.0.3.tar.bz2".
Macht man die Seite auf, geht auch gleich ein Download-Fenster auf, mit eben dieser Datei drin. Das ist doch die offizielle Upstream-Seite?
Danke und Gruss,
Markus

[sturmvogel]

Einfach mal das Projekt richtig öffnen
https://sourceforge.net/projects/zynadd ... bfx/3.0.6/

https://sourceforge.net/projects/zynadd ... naddsubfx/

[doktor5000]

und der Build-Lauf dauert eine Viertelstunde, um dann beim ersten "%make_build" auszusteigen.
Dann sind die gebauten Dateien doch noch im Build-Verzeichnis.
Gibt es eine Möglichkeit, nach Korrektur an einer bestimmten Stelle, hier das erste Vorkommen von "%make_build" wieder anzusetzen, statt von Null zu beginnen?

Innerhalb eines der Abschnitte nach bestimmten Befehlen nicht. Man kann aber mit dem Schalter --short-circuit für rpmbuild den Abschnitt (z.B. %build oder %install) angeben, bei dem quasi begonnen werden soll. So in etwa:

Code: Alles auswählen

rpmbuild -bc --short-circuit zynaddsubfx.spec

Für weitere Details siehe die man-Page von rpmbuild.