Created attachment 13024 [details]
This bug is perhaps for Wally who packages Guayadeque, but I wonder if it's a
Packaging problem ? Upstream bug ?
I have been using Guayadeque for some years without any problem on my main computer (mageia6 mageia7 mageia8) x86_64
I just installed Guyadeque on an old little laptop (Compaq mini 311 with mageia8 i586) that I use when I travel or navigate (with OpenCPN that I maintain).
When I launch Guayadeque on this i586 system it crashes immediately : core dumped !
(I attached the debug file)
I don't understand why because the same versions of the required rpms are installed on both of the systems
I tried to rebuild Guayadeque with the last git version inside mock and installed it on the i586 system : no change
Before sending the debug file upstream I need to be sure it's not specific to mageia8 i586 (no problem on x86_64) or to my old laptop
It would be useful that someone having a i586 system on an other kind of computer may test guayadeque and verify if it crashes too
guayadeque crashes on i586 but not on x86.64 =>
guayadeque crashes on i586 but not on x86_64
Thank you for the report, Philippe.
I am asking around to see whether anybody has 32-bit hardware to try this. Somebody may try a VM, but real hardware is better.
Len: can you please post on QA-discuss? It is dead easy to try.
lewyssmith, tarazed25, westel
Checked on "Foolishness," my Dell Inspiron 5100, 32-bit P4, 2 GB RAM, Radeon RV200 graphics, 32-bit Xfce system.
Installed guayadeque and dependencies, with no issues. Ran it from the command line using the command "guayadeque" with no options. A window popped up, indicating a crash. The following messages appeared in the terminal:
17:28:52: Created the configuration folder
17:28:52: Created the lyrics folder
17:28:52: Created the collections folder
17:28:52: Created the Radios folder
17:28:52: Created the Jamendo folder
17:28:52: Created the Magnatune folder
17:28:52: Created the Podcasts folder
17:28:52: Created the Layouts folder
17:28:52: Created the default configuration file
17:28:52: Created the default equalizers file
17:28:52: Created the default lyrics sources file
05:28:53 PM: Initialized locale ( en_US )
sh: line 1: addr2line: command not found
05:29:52 PM: A debug report has been generated. It can be found in
And includes the following files:
guayadeque.xml: process context description
Please send this report to the program maintainer, thank you!
Aborted (core dumped)
So, it would appear that the program started, but ran into a script command that it couldn't execute. I'm not a coder by any means, but I suspect a missing dependency.
Created attachment 13028 [details]
TJ's debug report file
My crash also generated a debug report file, probably similar to that of the reporter.
Indeed the debug report file you attached is exactly the same as the beginning of mine
But mine ends with some more lines :
<frame level="0" function="Guayadeque::guMainApp::OnFatalException()" offset="0" address="0x81a6bc2"/>
<frame level="1" offset="0x1a27b8" address="0xb7e6c7b8" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="2" function="__kernel_sigreturn" offset="0" address="0xb7f81560" module="linux-gate.so.1"/>
<frame level="3" offset="0x26078" address="0xb6a82078" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="4" offset="0x5d797" address="0xb6ab9797" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="5" offset="0xb02ac" address="0xb6b0c2ac" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="6" offset="0x4b027" address="0xb6aa7027" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="7" offset="0xc071b" address="0xb6b1c71b" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="8" offset="0x138e61" address="0xb6b94e61" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="9" function="wxSQLite3Database::Open(wxString const&, wxMemoryBuffer const&, int)" offset="0x8c" address="0xb6ba8bec" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="10" function="wxSQLite3Database::Open(wxString const&, wxString const&, int)" offset="0x114" address="0xb6ba8fc4" module="/lib/libwx_gtk3u_wxsqlite3-3.1.so.0"/>
<frame level="11" function="Guayadeque::guDb::Open(wxString const&)" offset="0" address="0x81da999"/>
<frame level="12" function="Guayadeque::guDb::guDb(wxString const&)" offset="0" address="0x81daa4c"/>
<frame level="13" function="Guayadeque::guDbCache::guDbCache(wxString const&)" offset="0" address="0x81dadf5"/>
<frame level="14" function="Guayadeque::guMainApp::OnInit()" offset="0" address="0x81a54c6"/>
<frame level="15" function="wxEntry(int&, wchar_t**)" offset="0x86" address="0xb7db6406" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="16" function="wxEntry(int&, char**)" offset="0x33" address="0xb7db6eb3" module="/lib/libwx_baseu-3.1.so.5"/>
<frame level="17" function="main" offset="0" address="0x819ac0e"/>
<frame level="18" function="__libc_start_main" offset="0x106" address="0xb65a9e86" module="/lib/libc.so.6"/>
<frame level="19" function="_start" offset="0" address="0x819f521"/>
It seems that there's a problem specific to 32 bits arch : stack overflow ?
Unless someone find a reason specific for the mageia i586 rpm
I will open an issue on the anonbeat github (he is really fast responsive, and already solved a little problem when building upon wxwidgets 3.1.4 that I reported )
I just sent an issue report to anonbeat
That doesn't prevent to dig on Mageia's side
Perhaps to test with cauldron 32bits installed to verify if the last builds are OK
Thank you TJ for such a rapid confirmation.
And Philippe for raising this upstream.
In the light of "I will open an issue on the anonbeat github (he is really fast responsive", I think we should await this upstream response before passing this to Jani; whom I am CC'ing as advanced warning.
tarazed25, westel =>
Yes we may await the upstream response... and it may quickly happen :
I have sent a mail to Juan Rios (aka anonbeat) , besides opening a new issue (mails are more quickly read than new issues on github...)
He immediately answered :
<< I will take a look but for what I saw on github it looks like its a wxsqlite problem... but I will try to reproduce the problem. >>
There are not lots of distributions continuing to support 32bits processors, (fortunately Mageia, besides Debian and some Debian forks) and so far not so much users facing this kind of bug ...
That's certainly why noone rang the bell before !
Nevertheless we may perhaps dig on our side :
Indeed as we can see in the last 20 lines of the attached debug file there seems to be a problem of stack with wxsqlite :
not enough memory available ? certainly no : guayadeque occupies only 54 Mbytes
not enough memory allowed to the stack by the program itself
using multihreading with a one core processor ?
problem of arch (i586 might be not compatible ?)
kernel problem (I tried several i586 kernels leading to the same crash)
Unless this was caused by the use of a snapshot of a prerelease of wxgtk 3.1.5 to build guayadeque and wxsqlite (that would be a Mageia problem and not an upstream one)
This might be tested on Cauldron rebuilding this staff on the final release of wxgtk 3.1.5
Unfortunately I don't have 32 bit HW available or possibility to install 32 bit Mageia to real HW ATM. However I tried i586 guayadeque with Virtualbox and wasn't able to reproduce the crash.
I think it indeed needs real hardware to be reproduced (like Thomas could do)
Unfortunately there are less and less such hardware users... and less and less distributions for this old kind of hardware (planned obsolescence !)
And maybe it won't be neither possible nor worth digging this for the upstream developper ... nor for the packagers...
One difference between my hardware and the usual VirtualBox install is the "processor" and therefore the kernel that is being used.
My hardware has a P4 processor, an i686, and therefore is supposed to work best with the features of kernel-desktop. The default 32-bit "processor" emulated by Vbox is an i586 processor, and can't function with kernel-desktop. It needs kernel-desktop586.
Usually, this difference means that some 32-bit programs will work on the newer processor, but not the older one. But, it's not hard (at least not for me, someone who isn't a coder) to imagine a case where the reverse could be true, where it could be that the program works with the desktop586 kernel/processor and not the desktop kernel/processor.
There also have been cases where the 32-bit server kernel worked when the desktop kernel didn't.
I don't know if simply installing the other kernel(s) on my hardware would do the trick, but I can give it a try.
Changing to kernel-desktop586 made no difference.
I knew it was a long shot, but I had to try.
I tried it on a 32-bit install on x86_64 hardware, and it crashed there, too. But as in Comment 9, when I tried it in Vbox, it didn't crash.
Most strange. Oh, well. On to other things...
(In reply to Thomas Andrews from comment #12)
> Changing to kernel-desktop586 made no difference.
> I knew it was a long shot, but I had to try.
I tried several kernel too (kernel-desktop, kernel-desktop586) before opening this bug
Same crash for all of them
I'm gonna try kernel-server that I forgot to test !
Juan Rios tested on a virtual box with Mageia8 i586 installed :
He didn't use the rpm but compile itself guayadeque which didn't crash...
same as https://bugs.mageia.org/show_bug.cgi?id=29742#c9 and in https://bugs.mageia.org/show_bug.cgi?id=29742#c12
he has no 32bits computer nor real 64bits computer with mageiai586 installed...
On my side :
I tried with kernel-server kernel-desktop kernel-desktop586
I'm gonna tried to build on a real 32bits hardware !
I built the rpm on my old 32bits mini computer (it took 2 hours...)
I installed it
I attach the debug file
There seems to be a problem with wxgtk3.1 on 32bits hardware
Created attachment 13050 [details]
debug file for guayadeque 0.4.6-7.git20211201.1.mga8 32 bits
debug file for guayadeque built on real 32bits hardware
Thank you for all your work on this.
>There seems to be a problem with wxgtk3.1 on 32bits hardware
My 64-bit system has:
Source RPM : wxgtk3.0-22.214.171.124-1.mga8.src.rpm
Source RPM : wxgtk-3.1.5-0.git20201230.1.mga8.src.rpm ? the 3.1 is different
Assigning this to DavidG who has seen both versions.
guayadeque crashes on i586 but not on x86_64 =>
guayadeque crashes on i586 but not on x86_64; wxgtk-3.1 is suspectedSource RPM:
guayadeque 0.4.6-7.git20201222.2.mga8 =>
guayadeque 0.4.6-7.git20201222.2.mga8, wxgtk-3.1.5-0.git20201230.1.mga8.src.rpmAssignee:
Other applications are also affected.
"urmpq --whatrequires-recursive wxgtk3.1" returns a rather long list of packages that depend on it. Included are guayadeque, audacity, and gnuplot.
I installed audacity on both 32-bit and 64-bit systems, and it runs and plays an mp3 file with no problem. I did not try to do any editing with it.
Gnuplot is a different story. I tested gnuplot on Mageia 7 back in March, but didn't do any testing with the then-in-Cauldron Mageia 8. It worked well in Mageia 7, but...
With both arches, the result was the same: You can run gnuplot (or gnuplot-qt), and use a simple command like "plot sin(x)" (as suggested at https://riptutorial.com/gnuplot) and it plots the function with no issues. However, if I go to http://www.gnuplot.info/demo/ and download a more involved demo script, save it in a text file, and then try to run "gnuplot-qt <filename>" from the command line, the plot shows briefly on the screen and then gnuplot crashes back to the terminal.
Removing the UPSTREAM flag, since it now looks like the problem is probably in our packages somewhere. Also changing from i586 to all, because gnuplot appears to be affected on both arches.
guayadeque crashes on i586 but not on x86_64; wxgtk-3.1 is suspected =>
guayadeque crashes on i586 but not on x86_64; wxgtk-3.1 is suspected; gnuplot is affected on both arches
(In reply to Thomas Andrews from comment #19)
> Other applications are also affected.
> "urmpq --whatrequires-recursive wxgtk3.1" returns a rather long list of
> packages that depend on it. Included are guayadeque, audacity, and gnuplot.
you may add opencpn !
Gtk successive versions are not backward compatible :
We had some problem with OpenCPN and its plugins in Mageia8, rebuilt upon gtk3.1 when the prerelease appeared in cauldron for Mageia8
OpenCPN had been created for gtk3.0... worked well in Mageia7 but crashed in Mageia8, inexplicably : weeks of digging to understand why :
Finally we have had to rebuild them back with a strict BuildRequire gtk3.0 !!!
Back to Guayadeque
Guayadeque built upon gtk3.0 worked perfectly with Mageia7 32bits on my Compaq Mini311
Guayadeque built for Mageia8 64bits with the prerelease of gtk3.1 works well in Mageia8 but Juan Rios its developper had to modify several lines of the code he had created upon gtk3.0 (the packagers wrote to him because they couldn't build Guayadeque anymore in Cauldron for Mageia8)
Guayadeque (built upon the prerelease of gtk 3.1 and simply copied from Mageia8 to Cauldron ) crashed inside Cauldron for Mageia9 when I tested it... and Jani have had to rebuild it upon the final release of gtk 3.1
It works now but sends hundred of warnings about wxwidgets ...
Juan Rios is working on this too
It's really frustrating that something that works perfectly has to be rewritten because the basis programs used to build it are updated without backward compatibility
Crazy rush forward !
Shame on us ! it's not a guayadeque problem on 32bits systems
Juan Rios and me wrote some mails...
He installed Mageia8 32bits on a virtual machine
installed the rpm
But encountered no problem
Finally he asked me to build myself guayadeque with his own recipe :
"Can you build it with ./buildd so its built with debug information? That way the crash dump will include some information I can check"
So I cloned his last code on my 32bits Compaq mini
launched a console
cd to the guayadeque folder
then sudo install
the app appears in Mageia menu
Launch Guayadeque in a console it works !!!!
(only some gtk warnings about gtk widgets)
Launch Guayadeque from the Mageia menu it works !!!
Something wrong in the spec file ?
it's not a BS problem nor a mock problem because when I build the rpm on my 32bits system and install it it crashes !
guayadeque crashes on i586 but not on x86_64; wxgtk-3.1 is suspected; gnuplot is affected on both arches =>
guayadeque crashes on i586 but not on x86_64; packaging problem
NB To apply Juan'recipe, the same BuildRequires as for building the rpm was installed : no more nor less...
correcting a lapsus
> So I cloned his last code on my 32bits Compaq mini
> launched a console
> cd to the guayadeque folder
> enter ./buildd
> then sudo install
sudo make install instead of sudo install
Filing a new bug on Gnuplot.
(In reply to Thomas Andrews from comment #24)
> Filing a new bug on Gnuplot.
Gnuplot situation was invalid - user error, coming from inexperience.
I uninstalled the guayadeque program created following anonbeat's recipe on my 32bits Compaq mini
( from the guayadeque folder in /home/myname/ : sudo make uninstall ... )
On my 64bits, main computer I tried several times to modify the spec file and
rebuilt a package in mock mageia8 i586
Whatever I try, the rpm installed on my 32bits Compaq mini crashes
I uninstalled the rpm
If I use guayadeque built from source it works perfectly, even with an imported configuration folder to use an external drive mounted with fstab in the same path as the one of my 64bits computer (18 000 audio files)
I can't understand where is the problem when packaging for i586 system
The solution for me is to use the manually built program and not a rpm !!!
This seems to be not so easy to debug the packaging and test without having a real 32 bits system...
It's out of my limited skill
Try to build from sources with our build time flags. You can see them with
$ rpm --eval %set_build_flags
Then copy paste the lines to buildd scriptlet.
Created attachment 13053 [details]
buildd script for guayadeque
I was not sure where to add the mageia's flags
I added them at the end of the buildd script (after the && make (2) line )
have a glance at buildd-modified : next attached file
Created attachment 13054 [details]
modified buildd script
Here is the modified buildd script used to build from source inside the real 32 bits hardware which could build a working guayadeque with the simple build script
It will take 1 or 2 hours to build and test
Besides this in the spec file for Mageia there are 2 useless files now:
# remove bundled libs
rm -rf src/wx/wxsql* src/wxsqlite3
since there is no more bundled source of wxsqlite3
Hi again Jani
I built guayadeque with the buildd-modified script
No problem to build (except a warning about a missing dependency : libindicate that is useless out of ubuntu)
I installed it
Unless I added the mageia flags in the wrong place, adding them doesn't change anything when building and installing the program from source (not packaging!!!)
(In reply to Philippe Didier from comment #30)
> Unless I added the mageia flags in the wrong place, adding them doesn't
> change anything when building and installing the program from source (not
Build flags should be set, of course, before the build. Add them before cmake call.
(In reply to Jani Välimaa from comment #31)
> (In reply to Philippe Didier from comment #30)
> > Unless I added the mageia flags in the wrong place, adding them doesn't
> > change anything when building and installing the program from source (not
> > packaging!!!)
> Build flags should be set, of course, before the build. Add them before
> cmake call.
I didn't know where to insert this
(I have still a lot to learn)
I'm gonna do this in the right way
But this will take 1 or 2 hours, unless the build process aborts
I rebuilt inserting the build flags in the right place inside the buildd script
I installed the program and it crashed immediately when launched
the debug file is the same as the first attached
It seems there's a stack overflow
The problem comes perhaps from this : -fstack-protector --param=ssp-buffer-size=4
My processor is an intel Atom n270
That may explain why
a simple build gives a working program
when the rpm (or the build with mageia build flags) gives a crashing program.
The Mageia macros are OK for more recent processors but not for such old as mine .
guayadeque crashes on i586 but not on x86_64; packaging problem =>
guayadeque crashes on i586 but not on x86_64; packaging problem with Mageia's build flag macro
The bug appears apparently only on real old 32 bits hardware (not inside virtualbox with mageiai586), like for Thomas Andrews and me, with the rpm built with Mageia build flags.
It's not strictly a guayadeque bug and absolutely not an upstream bug since simply build from source it'OK
It seems to be a Mageia packaging problem concerning only old real i586 hardware...
Is there a way to add something in the spec so that these build flags are not used for i586 but only for 64bits :
blabla = 0
blabla = 1
Unless this impact more recent hardware that afford those build flags
With a wider look : are there other packaged programs crashing on real i586 hardware with such stack problems ?
Does it need to create a conditional build_flags depending on arch
(In reply to Philippe Didier from comment #34)
> Hi Jani
> The bug appears apparently only on real old 32 bits hardware (not inside
> virtualbox with mageiai586), like for Thomas Andrews and me, with the rpm
> built with Mageia build flags.
> It's not strictly a guayadeque bug and absolutely not an upstream bug since
> simply build from source it'OK
> It seems to be a Mageia packaging problem concerning only old real i586
A bit of a correction, Phillipe. Please see Comment 13. I tried guayadeque on a 32-bit install on 64-bit hardware, and it crashed.
Specifically, the hardware is as follows: AMD Phenom II X4 910, ASRock A790GXH/128M motherboard, 8GB DDR2 RAM, AMD HD 8490 graphics card, and it shouldn't matter, but Atheros AR92BX wifi card. The install is a Plasma system, installed using netinstall at the time, and is using the i586 server kernel. \
Same hardware, only with a 64-bit Plasma install, and it did NOT crash.
Thanks Thomas for this correction
So that means that a 32-bits install on real hardware induces crashes of packaged guayadeque (even on your 64bits hardware)
when a 32-bits install inside a virtualbox doesn't ! (even on your 64bits hardware where a real install induces a crash !!!?)
I may add that the crash happens whatever kernel is used on my real hardware (Compaq mini311) with a 32bits install (I tried kernel-desktop, kernel-desktop586, kernel-server, with several versions)
That may mean too that a virtualbox doesn't plainly function like real hardware !
and that the way a virtualbox functions depends on the hardware used to test :
Jani didn't get a crash on his hardware,
Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't get a crash with Mageia 586 installed inside a virtualbox on his hardware,
when you got a crash inside the virtualbox on your own hardware
It's more and more complex to understand... and it seems that a virtual machine doesn't help to debug !
The only track that I found is that wxsqlite apparently induces a stack overflow when guayadeque is built with the Mageia's build flags for a 32bits system
Sorry, (English is not my natural language) in my previous comment these sentences were not clear :
> That may mean too that a virtualbox doesn't plainly function like real
> hardware !
> and that the way a virtualbox functions depends on the hardware used to test
> Jani didn't get a crash on his hardware,
> Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't
> get a crash with Mageia 586 installed inside a virtualbox on his hardware,
> when you got a crash inside the virtualbox on your own hardware
It's clearer written this way
That may mean that a 32bits install inside a virtualbox doesn't plainly function like a 32bits install on a real hardware ! (bad news for testing...)
- Jani didn't get a crash inside a virtualbox on his hardware,
- Juan Rios (aka anonbeat the Guayadeque developper) told me that he didn't
get a crash with Mageia 586 installed inside a virtualbox on his hardware,
- Thomas got no crash inside a virtualbox on his own hardware, where a real install of 32bits version of Mageia caused the crash
Besides this a real install of Mageia 586 on the hardware induces a crash whatever the processor is (32bits like mine, 64bits like Thomas'one), and whatever the kernel we use (kernel-desktop, kernel-desktop586, kernel-server)
Maybe some other programs satisfying the test inside a virtualbox will crash on a real 32bits install...
That would create a problem to reproduce some reported bugs for the QA, or the bugsquad or the maintainers, if they can't use some hardware with a real 32bits install.
Fortunately Thomas could, confirming the bug this way, and encouraging to dig to understand where this bug comes from.
The crash only happens in my i586 vb guest if the following packages are
(medium "Core Updates Testing (distrib5)")
libwx_baseu3.1_5 3.1.5 1.mga8 i586
libwx_baseu_xml3.1_5 3.1.5 1.mga8 i586
libwx_gtk3u_aui3.1_5 3.1.5 1.mga8 i586
libwx_gtk3u_core3.1_5 3.1.5 1.mga8 i586
libwx_gtk3u_html3.1_5 3.1.5 1.mga8 i586
libwx_gtk3u_qa3.1_5 3.1.5 1.mga8 i586
wxgtk3.1 3.1.5 1.mga8 i586
With the core release version of those packages it works.
On my x86-64 host with those packages installed, it crashes too ...
guayadeque: symbol lookup error: /lib64/libwx_gtk3u_qa-3.1.so.5: undefined symbol: _ZN19wxTopLevelWindowGTK10SetMinSizeERK6wxSize, version WXU_3.1
(In reply to Dave Hodgins from comment #38)
> The crash only happens in my i586 vb guest if the following packages are
> (medium "Core Updates Testing (distrib5)")
> libwx_baseu3.1_5 3.1.5 1.mga8 i586
> libwx_baseu_xml3.1_5 3.1.5 1.mga8 i586
> libwx_gtk3u_aui3.1_5 3.1.5 1.mga8 i586
> libwx_gtk3u_core3.1_5 3.1.5 1.mga8 i586
> libwx_gtk3u_html3.1_5 3.1.5 1.mga8 i586
> libwx_gtk3u_qa3.1_5 3.1.5 1.mga8 i586
> wxgtk3.1 3.1.5 1.mga8 i586
> With the core release version of those packages it works.
> On my x86-64 host with those packages installed, it crashes too ...
> $ guayadeque
> guayadeque: symbol lookup error: /lib64/libwx_gtk3u_qa-3.1.so.5: undefined
> symbol: _ZN19wxTopLevelWindowGTK10SetMinSizeERK6wxSize, version WXU_3.1
On my 32 bits system the Core Updates Testing repo is not activated
So there are only the prerelease of those libs from Core Repo (3.1.5-0.git20201230.1.mga8) upon which guayadeque was built
In a vb guest you might not use a version of wxgtk different from what was used to build the guayadeque package, or other packages depending of those libs...
You might get bad surprises in your vb with other packages...
If you use the testing repo you should have to rebuild the Guayadeque rpm to be complient with those new versions
With Mageia 64 bits installed on your hardware, you will certainly obtain a crash if you activate the testing repos and install :
lib64wx_baseu3.1_5 3.1.5 1.mga8 x86_64
lib64wx_baseu_xml3.1_5 3.1.5 1.mga8 x86_64
lib64wx_gtk3u_aui3.1_5 3.1.5 1.mga8 x86_64
lib64wx_gtk3u_core3.1_5 3.1.5 1.mga8 x86_64
lib64wx_gtk3u_html3.1_5 3.1.5 1.mga8 x86_64
lib64wx_gtk3u_qa3.1_5 3.1.5 1.mga8 x86_64
wxgtk3.1 3.1.5 1.mga8 x86_64
Each version of those libs are not backward compatible and a rebuild is needed for packages depending on them...
You might get crashes with guayadeque and with other packages depending of wxgtk !
The problem I encountered is not caused by a problem of libwx or wxgtk version
but apparently caused by the rpm build_flags since I experienced that :
- with a rpm built on my 32bits computer (updated but without Core Updates Testing repo being activated) when I install and launch it I get a crash whichever git clone of Guayadeque I use :
guayadeque-0.4.6-7.git20201222.2 or guayadeque-0.4.6-8.git20211201.1
- with this program simply built from each of those 2 git clones
with ./build & sudo make install
I get no crash
NB to be sure not to have artifacts I didn't build my rpms inside mock on my 64bits computer but on my old 32 bits computer (it took 2 hours each time) :
Debugging takes time sometimes !
"There's no solution for this since we can't prevent the use of the build time flags when building a rpm for Mageia"
If that's the case, then we should close this bug as a "Won't Fix."
Moreover, we should seriously consider not offering a 32-bit version of guayadeque in Mageia 9 and beyond. And if that's not possible, then perhaps we should consider dropping it altogether.
The fact that a user can make it work if he has sufficient skills is not enough. We should not offer an rpm that we know won't work.
I don't think Guayadeque should be simply dropped : it works perfectly on a 64bits system
The problem occurs only with the 32bits rpm on old 32bits i586 hardware (not inside a virtualbox !) : guayadeque segfaults
This is a wilder problem about rpm building for i586 without sse sse2 or mmx
(you may have a glance at this thread in gmane.linux.mageia.devel :
32bit i586 and SSE/SSE2 instructions slipping )
It seems that Mageia9 will no more have rpms built for such old hardware
But Mageia8 intended to work on this ...
I wonder if there is a way to modify the guayadeque spec so that the rpm build flags are not applied for this particular program
Unless the decision is taken of building rpms strictly for i686 and no more for i586 !
(maybe other programs will be concerned )
In this case this needs a warning for the users
(Mageia with Debian were two of the last rare distribution supporting 32bits hardware)
Planned obsolescence !!!
(In reply to Philippe Didier from comment #41)
> Hi Thomas
> I don't think Guayadeque should be simply dropped : it works perfectly on a
> 64bits system
> The problem occurs only with the 32bits rpm on old 32bits i586 hardware (not
> inside a virtualbox !) : guayadeque segfaults
> This is a wilder problem about rpm building for i586 without sse sse2 or mmx
> (you may have a glance at this thread in gmane.linux.mageia.devel :
> 32bit i586 and SSE/SSE2 instructions slipping )
> It seems that Mageia9 will no more have rpms built for such old hardware
> But Mageia8 intended to work on this ...
> I wonder if there is a way to modify the guayadeque spec so that the rpm
> build flags are not applied for this particular program
> Unless the decision is taken of building rpms strictly for i686 and no more
> for i586 !
> (maybe other programs will be concerned )
> In this case this needs a warning for the users
> (Mageia with Debian were two of the last rare distribution supporting 32bits
> Planned obsolescence !!!
Except that in this particular case, that doesn't apply.
The 32-bit CPU in Comment 3 is a P4, which IS i686 hardware, and supports sse, sse2, and mmx. And, it is using the desktop kernel, not the less-able desktop586 kernel that is designed for that older, less-capable hardware.
Also, the CPU in Comment 13 is a Phenom II X4 910, and is using the server kernel, which certainly supports any i686 capabilities. I tested the new build of guayadeque on a real 32-bit install on that hardware, NOT in VirtualBox, and it failed.
So, it's not just older 32-bit hardware that's failing. It's our 32-bit build that is, for some other reason. A simple warning that the 32-bit version might not work on SOME hardware won't cut it. From what I've seen, it doesn't work on ANY real hardware.
I am setting this to depend on wxgtk3.1 update as I think we should let that out first (including updated Guayadeque even if it still fail often on 32 bit)
We may say that this doesn't depends on
the Mageia8 i586rpm of Guayadeque from Core Repo (built with the prerelease of wxgtk)
already crashed on some 32 bits hardwares when it was OK for 64bits
This is not at all linked to wxgtk but only a consequence of the rpm build flags used after Mageia7
You may remove this depending link since guayadeque works perfectly on 64bits, as it did before, after having been rebuilt in Updates-Testing upon wgtk 3.1.5 final release
if you update all the wxgtk stuff in the same time
When the rpm from updates-testing is built for i586 it crashes the same way as before : no change
this 29742 bug is stricly a "rpm build flags" bug
I know this is a separate issue :)
Just intended to note to remember not to ship to updates a new Guayadeque compiled with new wxgtk3.1, before new wxgtk3.1 is released.