The following comments from bug 32231 explain what happens with the current version from core and with the update proposed to test in bug 32532 (which solved an other kind of crash for other users)

https://bugs.mageia.org/show_bug.cgi?id=32231#c54
https://bugs.mageia.org/attachment.cgi?id=14160
https://bugs.mageia.org/show_bug.cgi?id=32231#c72


The reason why the Guayadeque rpms crashes on some 64bits systems and not on other has not yet an explanation

NB These users can't even use the solution of disabling fader and equalizer to prevent the crash as for https://bugs.mageia.org/show_bug.cgi?id=32532
as suggested by Jani
(https://bugs.mageia.org/show_bug.cgi?id=32231#c21)
Guaydeque crashes immediately for them (they can't get the interface of the program where to modify the playback preferences)

This useful part of the bug report created by Guayadeque itself 
https://bugs.mageia.org/attachment.cgi?id=14160
indicates that something is wrong for these users with the use of libwx_gtk3u_wxsqlite3-3.2.so.0

 <stack>
    <frame level="0" function="Guayadeque::guMainApp::OnFatalException()" offset="0" address="0x56ee5a"/>
    <frame level="1" offset="0x1d8570" address="0x7f36a3fd8570" module="/lib64/libwx_baseu-3.2.so.0"/>
    <frame level="2" offset="0x36960" address="0x7f36a2664960" module="/lib64/libc.so.6"/>
    <frame level="3" function="sqlite3_initialize" offset="0x3f7" address="0x7f36a2bf1b17" module="/lib64/libwx_gtk3u_wxsqlite3-3.2.so.0"/>
    <frame level="4" offset="0x14827b" address="0x7f36a2ca427b" module="/lib64/libwx_gtk3u_wxsqlite3-3.2.so.0"/>
    <frame level="5" function="wxSQLite3Database::Open(wxString const&amp;, wxMemoryBuffer const&amp;, int)" offset="0x8b" address="0x7f36a2cb458b" module="/lib64/libwx_gtk3u_wxsqlite3-3.2.so.0"/>
    <frame level="6" function="wxSQLite3Database::Open(wxString const&amp;, wxString const&amp;, int)" offset="0x11c" address="0x7f36a2cb487c" module="/lib64/libwx_gtk3u_wxsqlite3-3.2.so.0"/>
    <frame level="7" function="Guayadeque::guDb::Open(wxString const&amp;)" offset="0" address="0x5af1df"/>
    <frame level="8" function="Guayadeque::guDb::guDb(wxString const&amp;)" offset="0" address="0x5af28c"/>
    <frame level="9" function="Guayadeque::guDbCache::guDbCache(wxString const&amp;)" offset="0" address="0x5af720"/>
    <frame level="10" function="Guayadeque::guMainApp::OnInit()" offset="0" address="0x56e0ae"/>
    <frame level="11" function="wxEntry(int&amp;, wchar_t**)" offset="0x6a" address="0x7f36a3f1ec8a" module="/lib64/libwx_baseu-3.2.so.0"/>
    <frame level="12" function="main" offset="0" address="0x561f28"/>
    <frame level="13" offset="0x236b7" address="0x7f36a26516b7" module="/lib64/libc.so.6"/>
    <frame level="14" function="__libc_start_main" offset="0x85" address="0x7f36a2651775" module="/lib64/libc.so.6"/>
    <frame level="15" function="_start" offset="0" address="0x567471"/>
  </stack>

Summary: Guayadeque crashes immediately when launched on some 64 bits systems => Guayadeque crashes immediately for some userswhen launched on some 64 bits systems

Please test with wxsqlite3-4.9.1-1.1.mga9 in core/updates_testing.

SRPMS:
wxsqlite3-4.9.1-1.1.mga9

RPMS:
lib(64)wx_gtk3u_wxsqlite3_3.2_0-4.9.1-1.1.mga9
lib(64)wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.1.mga9

Thanks Jani

@ katnatek
@ Thomas Andrews
May you test it to verify if it corrects it for the current version and for the updated version ?
(I will test it... but I'm not concerned by this bug ;)

I installed your update 
NB I use Guayadeque from a rpm built with mock and the corrected spec file
https://bugs.mageia.org/attachment.cgi?id=14167

I renamed my /home/myusername/.guayadeque to /home/myusername/.guayadequebak
so that guayadeque builds a new database
As I thought no problem for me (I had not before)

I then deleted this newly created /home/myusername/.guayadeque
and renamed /home/myusername/.guayadequebak to /home/myusername/.guayadeque

Guayadeque starts immediately with the old database and works perfectly

But I don't know if this will change anything for the others

PS 
maybe to really test we need to rebuild guayadeque 
with this new lib(64)wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.1.mga9

Hi again Jani
I have rebuilt guayadeque inside mock after having installed inside mock your last
lib64wx_gtk3u_wxsqlite3_3.2_0-4.9.1-1.1.mga9
lib64wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.1.mga9
and launched mock with --no-clean option 
So that it is now built upon the last version

Then I installed guayadeque and tested it again the same way as in https://bugs.mageia.org/show_bug.cgi?id=32535#c6

No problem for me

One last question
When the badly versioned of the guayadeque.rpm will be removed by sysadmins from Cauldron and Mageia9/core/updates_testing
I may submit it again with the corrected spec file

Will it be built for Mageia9/core/updates_testing with your last versions of 
lib(64)wx_gtk3u_wxsqlite3_3.2_0-4.9.1-1.1.mga9
lib(64)wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.1.mga9
that are present in Mageia9/core/updates_testing ?
Or with the version from Mageia9/core ?

Test 1
Install the previous testing guayadeque package with the testing lib(64)wx_gtk3u_wxsqlite3_3.2_0-4.9.1-1.1.mga9

The list maybe don't have all the wx requires because I have other application that also use that libraries

LC_ALL=C urpmi guayadeque
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release (Installer) (DVD1)")
  lib64gpod4                     0.8.3        24.mga9       x86_64  
  lib64sgutils2_2                1.46         2.mga9        x86_64  
  libgpod                        0.8.3        24.mga9       x86_64  
(medium "QA Testing (64-bit)")
  guayadeque                     0.4.8        4.git2023111> x86_64  
  lib64wx_gtk3u_wxsqlite3_3.2_0  4.9.1        1.1.mga9      x86_64  
11MB of additional disk space will be used.
3.5MB of packages will be retrieved.
Proceed with the installation of the 5 packages? (Y/n) y


installing //home/katnatek/qa-testing/x86_64/guayadeque-0.4.8-4.git20231115.1.mga9.x86_64.rpm
/mnt/MageiaDVD/x86_64/media/core/lib64gpod4-0.8.3-24.mga9.x86_64.rpm
//home/katnatek/qa-testing/x86_64/lib64wx_gtk3u_wxsqlite3_3.2_0-4.9.1-1.1.mga9.x86_64.rpm
/mnt/MageiaDVD/x86_64/media/core/lib64sgutils2_2-1.46-2.mga9.x86_64.rpm
/mnt/MageiaDVD/x86_64/media/core/libgpod-0.8.3-24.mga9.x86_64.rpm
Preparing...                     ###########################################################################################
      1/5: lib64sgutils2_2       ###########################################################################################
      2/5: libgpod               ###########################################################################################
      3/5: lib64gpod4            ###########################################################################################
      4/5: lib64wx_gtk3u_wxsqlite3_3.2_0
                                 ###########################################################################################
      5/5: guayadeque     

Run guayadeque as users crash I will try rebuild guyadeque against this new wx library but, why don't like to disable as-needed ldflags to make it works ?

Hi

before rebuilding  with disabling as-needed ldflags (that I never had to use)

I am still thinking there's an hidden dependency installed on my computer that is  not on yours
Would you please run this in a console :

rpm -qa |sort > rpm.list

and attach this file so that I can compare with mine : 
I will try to uninstall some rpms that are on my computers and not on yours and then launch guayadeque to find the culprit

(In reply to Philippe Didier from comment #10)
> Hi
> 
> before rebuilding  with disabling as-needed ldflags (that I never had to use)
> 
> I am still thinking there's an hidden dependency installed on my computer
> that is  not on yours
> Would you please run this in a console :
> 
> rpm -qa |sort > rpm.list
> 
> and attach this file so that I can compare with mine : 
> I will try to uninstall some rpms that are on my computers and not on yours
> and then launch guayadeque to find the culprit

This is again starting to be a mess. Lets avoid fuss, and keep this simple.

I'll provide a list of extra pkgs that are required if the pkg is built without  -Wl,--as-needed.

Sorry for the mess
Didn't know that there was a better way to find which required pkg is missing
Thanks for your help ...

Test 2 
Install guayadeque build from the testing srpm against the testing wxsqlite (I did have to build in my copr)

Run as user and crash

Log of my build of guyadeque https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06668017-guayadeque/builder-live.log.gz

(In reply to Jani Välimaa from comment #11)
> (In reply to Philippe Didier from comment #10)
> > Hi
> > 
> > before rebuilding  with disabling as-needed ldflags (that I never had to use)
> > 
> > I am still thinking there's an hidden dependency installed on my computer
> > that is  not on yours
> > Would you please run this in a console :
> > 
> > rpm -qa |sort > rpm.list
> > 
> > and attach this file so that I can compare with mine : 
> > I will try to uninstall some rpms that are on my computers and not on yours
> > and then launch guayadeque to find the culprit
> 
> This is again starting to be a mess. Lets avoid fuss, and keep this simple.
> 
> I'll provide a list of extra pkgs that are required if the pkg is built
> without  -Wl,--as-needed.

I avoid you that and say that 0

Perhaps this will help...

guayadeque-0.4.8-4.git20231115.1.mga9.x86_64.rpm is what's currently installed. After deleting the .guayadeque folder, I ran it from the command line and saw this:

[tom@localhost ~]$ guayadeque 
11:59:18: Created the configuration folder
11:59:18: Created the lyrics folder
11:59:18: Created the collections folder
11:59:18: Created the Radios folder
11:59:18: Created the Jamendo folder
11:59:18: Created the Magnatune folder
11:59:18: Created the Podcasts folder
11:59:18: Created the Layouts folder
11:59:18: Created the default configuration file
11:59:18: Created the default equalizers file
11:59:18: Created the default lyrics sources file
11:59:18 AM: Initialized locale ( en_US )
sh: line 1: addr2line: command not found
11:59:29 AM: A debug report has been generated. It can be found in
        /tmp/guayadeque_dbgrpt-4209-20231119T115918

And includes the following files:
        guayadeque.xml: process context description

Please send this report to the program maintainer, thank you!
Aborted (core dumped)


Looks to me like it's not finding the command "addr2line" anywhere. The missing dependency, perhaps?

Removed the updated guayadeque, and installed the one from core_release. Deleted the .guayadeque folder again, and ran the app once more from the command line, seeing the same result as in comment 15.

I can run an strace if it would be helpful.

There're unused/extra libraries when building without -Wl,--as-needed.

Warning: unused libraries in /usr/bin/guayadeque:
 libgstvideo-1.0.so.0
 libgstaudio-1.0.so.0
 libgstbase-1.0.so.0
 libsqlite3.so.0
 libz.so.1
 libimobiledevice-1.0.so.6
 libplist-2.0.so.3

Besides those 'urpmq --requires' shows also extra requires:
 libwx_baseu_net-3.2.so.0

The list of extra requires. I didn't check if they're pulled via other generated requires, though.
lib64gstreamer-plugins-base1.0_0
lib64sqlite3_0
lib64zlib1
lib64imobiledevice1.0_6
lib64plist2.0_3
lib64wx_baseu_net3.2_0

A search in MCC for the filename "addr2line" reveals several packages that provide it, and none of them are installed on this system.

(In reply to Jani Välimaa from comment #17)
> There're unused/extra libraries when building without -Wl,--as-needed.
> 
> Warning: unused libraries in /usr/bin/guayadeque:
>  libgstvideo-1.0.so.0
>  libgstaudio-1.0.so.0
>  libgstbase-1.0.so.0
>  libsqlite3.so.0
>  libz.so.1
>  libimobiledevice-1.0.so.6
>  libplist-2.0.so.3
> 
> Besides those 'urpmq --requires' shows also extra requires:
>  libwx_baseu_net-3.2.so.0
> 
> The list of extra requires. I didn't check if they're pulled via other
> generated requires, though.
> lib64gstreamer-plugins-base1.0_0
> lib64sqlite3_0
> lib64zlib1
> lib64imobiledevice1.0_6
> lib64plist2.0_3
> lib64wx_baseu_net3.2_0

I guess I already have that, because no extra package was installed in my test in both arches

(In reply to Thomas Andrews from comment #18)
> A search in MCC for the filename "addr2line" reveals several packages that
> provide it, and none of them are installed on this system.

are you sure of that? 
binutils-2.40-11.mga9.x86_64:/usr/bin/addr2line

Hi Thomas
Nice catch
Don't you have binutils installed ?
it provides addr2line
I have it installed on my compuer and it's required by lots of other programs !

@ katnatek
I saw that you don't use plasma as desktop
Plasma needs
 lib64imobiledevice1.0_6
 lib64plist2.0_3

Since Guayadeque has acces to Apple's Ipod  these rpms are needed

Are they installed on your computer ?

(In reply to Philippe Didier from comment #22)
> @ katnatek
> I saw that you don't use plasma as desktop
> Plasma needs
>  lib64imobiledevice1.0_6
>  lib64plist2.0_3
> 
> Since Guayadeque has acces to Apple's Ipod  these rpms are needed
> 
> Are they installed on your computer ?

rpm -q lib64imobiledevice1.0_6
lib64imobiledevice1.0_6-1.3.0-7.mga9

rpm -q lib64plist2.0_3
lib64plist2.0_3-2.2.0-4.mga9

BTW, I use for the moment lxqt but I have plasma X11 and also plasma wayland

(In reply to Jani Välimaa from comment #17)
> There're unused/extra libraries when building without -Wl,--as-needed.
> 
> Warning: unused libraries in /usr/bin/guayadeque:
>  libgstvideo-1.0.so.0
>  libgstaudio-1.0.so.0
>  libgstbase-1.0.so.0
>  libsqlite3.so.0
>  libz.so.1
>  libimobiledevice-1.0.so.6
>  libplist-2.0.so.3
> 
> Besides those 'urpmq --requires' shows also extra requires:
>  libwx_baseu_net-3.2.so.0
> 
> The list of extra requires. I didn't check if they're pulled via other
> generated requires, though.
> lib64gstreamer-plugins-base1.0_0
> lib64sqlite3_0
> lib64zlib1
> lib64imobiledevice1.0_6
> lib64plist2.0_3
> lib64wx_baseu_net3.2_0

I don't see that in my builds, perhaps because I add also

%global optflags %{optflags} -flto=auto

@ Jani
lib64wx_baseu_net3.2_0 is installed on my computer
it is required by
- audacity that is installed 
- opencpn that I maintain and is installed
- lib64wxgtku3.2-devel-3.2.1-3 that is installed
- lib64wx_gtk3u_wxsqlite3_3.2-devel-4.9.1-1.1. that is installed

We apparently need to add lib64wx_baseu_net3.2_0 as Requires

(this never appeared to me since it's installed for these 4 rpms !

@ katnatek
have you lib64wx_baseu_net3.2_0 installed on your computer ?
If no : install it and test guayadeque again
(after having deleted /home/yourusername/.guayadeque directory)

(In reply to katnatek from comment #20)
> (In reply to Thomas Andrews from comment #18)
> > A search in MCC for the filename "addr2line" reveals several packages that
> > provide it, and none of them are installed on this system.
> 
> are you sure of that? 
> binutils-2.40-11.mga9.x86_64:/usr/bin/addr2line

I'm sure. It surprised me too that it wasn't installed, but, this happens to be a very basic install, with nothing much beyond what the original install iso put there.

(In reply to Thomas Andrews from comment #27)
> (In reply to katnatek from comment #20)
> > (In reply to Thomas Andrews from comment #18)
> > > A search in MCC for the filename "addr2line" reveals several packages that
> > > provide it, and none of them are installed on this system.
> > 
> > are you sure of that? 
> > binutils-2.40-11.mga9.x86_64:/usr/bin/addr2line
> 
> I'm sure. It surprised me too that it wasn't installed, but, this happens to
> be a very basic install, with nothing much beyond what the original install
> iso put there.

Well that not is the cause
rpm -q binutils
binutils-2.40-11.mga9

(In reply to Philippe Didier from comment #26)
> @ katnatek
> have you lib64wx_baseu_net3.2_0 installed on your computer ?
> If no : install it and test guayadeque again
> (after having deleted /home/yourusername/.guayadeque directory)

rpm -q lib64wx_baseu_net3.2_0
lib64wx_baseu_net3.2_0-3.2.1-3.mga9

I would like to know if LD_DEBUG shows anything interesting.

$ LD_DEBUG=symbols LD_DEBUG_OUTPUT=guayadeque.log guayadeque

To get info about LD_DEBUG one can use:
$ LD_DEBUG=help cat

(In reply to katnatek from comment #28)
> (In reply to Thomas Andrews from comment #27)
> > (In reply to katnatek from comment #20)
> > > (In reply to Thomas Andrews from comment #18)
> > > > A search in MCC for the filename "addr2line" reveals several packages that
> > > > provide it, and none of them are installed on this system.
> > > 
> > > are you sure of that? 
> > > binutils-2.40-11.mga9.x86_64:/usr/bin/addr2line
> > 
> > I'm sure. It surprised me too that it wasn't installed, but, this happens to
> > be a very basic install, with nothing much beyond what the original install
> > iso put there.
> 
> Well that not is the cause
> rpm -q binutils
> binutils-2.40-11.mga9

That doesn't surprise me. urpmq --whatrequires-recursive binutils > binutils.txt produces an extremely long list of packages, but guayadeque is not among them. Since it needs that command, it should be, shouldn't it? Or is it supposed to get it from somewhere else?

(In reply to Thomas Andrews from comment #32)
> (In reply to katnatek from comment #28)
> > (In reply to Thomas Andrews from comment #27)
> > > (In reply to katnatek from comment #20)
> > > > (In reply to Thomas Andrews from comment #18)
> > > > > A search in MCC for the filename "addr2line" reveals several packages that
> > > > > provide it, and none of them are installed on this system.
> > > > 
> > > > are you sure of that? 
> > > > binutils-2.40-11.mga9.x86_64:/usr/bin/addr2line
> > > 
> > > I'm sure. It surprised me too that it wasn't installed, but, this happens to
> > > be a very basic install, with nothing much beyond what the original install
> > > iso put there.
> > 
> > Well that not is the cause
> > rpm -q binutils
> > binutils-2.40-11.mga9
> 
> That doesn't surprise me. urpmq --whatrequires-recursive binutils >
> binutils.txt produces an extremely long list of packages, but guayadeque is
> not among them. Since it needs that command, it should be, shouldn't it? Or
> is it supposed to get it from somewhere else?

Indeed binutils is required by lots of devel packages
If you don't use to build packages then binutils might be not installed !
Install it and then launch again guayadeque
You might not have again :
addr2line: command not found

and maybe no more problem ?

(In reply to Philippe Didier from comment #33)

> 
> Indeed binutils is required by lots of devel packages
> If you don't use to build packages then binutils might be not installed !
> Install it and then launch again guayadeque
> You might not have again :
> addr2line: command not found
> 
> and maybe no more problem ?

Of course it wasn't that easy. I didn't think it would be. Guayadeque still crashes right away, but now it no longer complains about not finding addr2line. 

Philippe, I believe that the best way for you to examine why guayadeque is crashing on systems without all the devel packages on your machine would be to create a new, basic Mageia 9 guest in VirtualBox, and play with that yourself.

I've already contributed too much to this mess of a bug. I'm not going to make it even worse by sending people off on wild goose chases because I don't know what I'm doing. I'll be back if it ever gets ready for QA, but until then I don't believe I can add anything useful.

CC: andrewsfarm => (none)

Thanks Thomas
You give the specific explanation of the first crash that you encountered
It was not so easy to suspect (I couldn't imagine that  binutils is not installed on every system !)

I will add 
Requires : binutils
to the spec file

We have now to find the second explanation of the crash that is now common to you and katnatek

Last tests
I installed Mageia9 in a virtual machine :
basic install from the iso (no rpm added)
updated it 
binutils is not installed by default !

1) I installed guayadeque from core
launch it => crash immediately

2) I installed binutils 
Launch guayadeque
add a path to some music OK
add a play list          OK
play => crash

3) launch guayadeque again
disable fader and equalizer
no more crash when playing ok

4) Update guayadeque from updates_testing
launch it
enable fader and equalizer
no more crash ok

I can't reproduce the crash describe by katnatek

It's not necessary to update lib64wx_gtk3u_wxsqlite3_3.2_0

Last tests

I installed Mageia9 in a virtual machine :
basic install from the iso (no rpm added)
updated it 
Effectively, binutils is not installed by default ! (I will add this requires in the spec file of guayadeque!)

1) I installed guayadeque from core (0.4.7-1)
launch it => crash immediately like for Thomas

2) I installed binutils 
Launch guayadeque
add a path to some music OK
add a play list          OK
play =>                  crash

3) launch guayadeque again
disable fader and equalizer
no more crash when playing  OK

4) Update guayadeque from updates_testing (0.4.8-4.git20231115.1)
launch it
enable fader and equalizer
no more crash           OK

I can't reproduce the crash described by katnatek 

@ Jani
PS
It's not necessary to update lib64wx_gtk3u_wxsqlite3_3.2_0 from 4.9.1-1 to 4.9.1-1.1
for guayadeque : it works without this update
Nevertheless, I updated it and it doesn't hurt !

Thank you everyone for all the testing, building etc. Especially Philippe.
Comments 40 & 41 report the same sequence of crashing to working.

Two things emerge:
1. It looks like guayadeque requires binutils.
2. Given the presenc of binutils, the version in updates_testing looks good.

(In reply to Philippe Didier from comment #40)
> 4) Update guayadeque from updates_testing
> launch it
> enable fader and equalizer
> no more crash ok
(In reply to Philippe Didier from comment #41)
> 4) Update guayadeque from updates_testing (0.4.8-4.git20231115.1)
> launch it
> enable fader and equalizer
> no more crash           OK

(In reply to Thomas Andrews from comment #32)
> That doesn't surprise me. urpmq --whatrequires-recursive binutils >
> binutils.txt produces an extremely long list of packages, but guayadeque is
> not among them.
 $ urpmq --whatrequires-recursive binutils | grep guayadeque
might have been easier. Conversely:
 $ urpmq --requires-recursive guayadeque | grep binutils
returns nothing. Without the grep, the list is huge.

Should the version in updates_testing be held in obeyance until the requires on binutils is added? Rather than yet another bug.
Or this bug be closed OK along with its mate bug 32532.

CC: (none) => lewyssmith

Hi Lewis
I made a comment https://bugs.mageia.org/show_bug.cgi?id=32532#c17

Indeed there will be a new rpm in updates_testing :
I made a mistake with the version numbering : 0.4.8-4.git20231115.1 is not right,
nevertheless that brought a solution to bug 32532


We were waiting for sysadmins to remove this rpm from 
Cauldron and  
Mageia9/core/updates_testing 
before submitting a better number : that should have  been : 0.4.7-3.git20231115.1 

But in the mean time I took the opportunity to modify again the spec and add Requires : binutils to correct partly this bug 32535... and the version will be now 0.4.7-3.git20231115.2

It's not yet submitted to Cauldron and  Mageia9/core/updates_testing ! nor tested

When bug 32532 will be closed as resolved for its own cause (as I think it may with 0.4.7-3.git20231115.2)
this won't resolve totally this bug 32535 nor the bug 32536 that will remain open

Nevertheless I will add a comment here to inform that a new rpm is provided when it will have been submitted

(In reply to Philippe Didier from comment #43)
> Hi Lewis
> I made a comment https://bugs.mageia.org/show_bug.cgi?id=32532#c17
> 
> Indeed there will be a new rpm in updates_testing :
> I made a mistake with the version numbering : 0.4.8-4.git20231115.1 is not
> right,
> nevertheless that brought a solution to bug 32532
> 
> 
> We were waiting for sysadmins to remove this rpm from 
> Cauldron and  
> Mageia9/core/updates_testing 
> before submitting a better number : that should have  been :
> 0.4.7-3.git20231115.1 
> 
> But in the mean time I took the opportunity to modify again the spec and add
> Requires : binutils to correct partly this bug 32535... and the version will
> be now 0.4.7-3.git20231115.2
> 

No, it's still 0.4.7-3.git20231115.1. Nothing was pushed to build system yet, so all changes until the submit should done without bumping the release.

Please revert the release bump in SVN, and don't forget to use SILENT in commit msg so it won't end up to %changelog.

That is all for me I ask to Jose Manual to test 0.4.8-4.git20231115.1  and work for him in VBOX and in real hardware.

I don't found another solution for my x86_64 and i586 systems, as long as you and Jani don't like the idea of disable as needed then close at less bug#32536 as wontfix

@Jani, can I remove the guyadeque logs from the blogdrake server?

Removing '-Wl,--as-needed' linker flag is OK, if it's the last resort. However it's still a workaround until we figure out what's really causing the crash.

Logs can be removed.

> > 
> > But in the mean time I took the opportunity to modify again the spec and add
> > Requires : binutils to correct partly this bug 32535... and the version will
> > be now 0.4.7-3.git20231115.2
> > 
> 
> No, it's still 0.4.7-3.git20231115.1. Nothing was pushed to build system
> yet, so all changes until the submit should done without bumping the release.
> 
> Please revert the release bump in SVN, and don't forget to use SILENT in
> commit msg so it won't end up to %changelog.

Ok 
Sorry ! since I had added the Requires : binutils I thought it was necessary to bump the release
I'm gonna revert it

(In reply to katnatek from comment #45)
> That is all for me I ask to Jose Manual to test 0.4.8-4.git20231115.1  and
> work for him in VBOX and in real hardware.
> 
> I don't found another solution for my x86_64 and i586 systems, as long as
> you and Jani don't like the idea of disable as needed then close at less
> bug#32536 as wontfix
> 

The worst bug to diagnose is the one that doesn't appear on all computers
We already found a first explanation thanks to Thomas :
we add Requires : binutils

The second explanation to find is : 
What explains the crash for you and for Thomas since he has installed binutils ?

This crash doesn't appear for me even in a VM where I installed a basic Mageia9
(see https://bugs.mageia.org/show_bug.cgi?id=32535#c41)
this crash doesn't appear for Jose Manual...

I am still thinking about an hidden dependency for you and Thomas

about bug 32536 (similar to the old bug 29742) maybe it's possible to create a conditional spec file !

> 
> No, it's still 0.4.7-3.git20231115.1. Nothing was pushed to build system
> yet, so all changes until the submit should done without bumping the release.
> 
> Please revert the release bump in SVN, and don't forget to use SILENT in
> commit msg so it won't end up to %changelog.

Hi Jani

I was on the way to revert the release bump but I saw that you kept it when adding 
- define _GUREVISION_ to have proper release string in app title bar

is it necessary to revert the release bump now ?

@ Jani
You apparently applied this change only for Cauldron ?
Do I need only to revert the release bump to Mageia9 ?

(In reply to Philippe Didier from comment #48)
> The worst bug to diagnose is the one that doesn't appear on all computers
> We already found a first explanation thanks to Thomas :
> we add Requires : binutils
> 
> The second explanation to find is : 
> What explains the crash for you and for Thomas since he has installed
> binutils ?
> 
> This crash doesn't appear for me even in a VM where I installed a basic
> Mageia9
> (see https://bugs.mageia.org/show_bug.cgi?id=32535#c41)
> this crash doesn't appear for Jose Manual..
Sorry the typo is "Jose Manuel"
> 
> I am still thinking about an hidden dependency for you and Thomas
> 
> about bug 32536 (similar to the old bug 29742) maybe it's possible to create
> a conditional spec file !

I think this and 32536 is the same bug, but who knows 2 bugs with the same "solution" not sound weird to me anymore XD

@Jani & Philippe , with the amount of warnings building this without ninja https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06671952-guayadeque/builder-live.log.gz (use the search function of your browser to go to 30% and start to scroll down) I think could a bad use of a function or a missing include in somewhere, why crash for me and Thomas is beyond of my current abilities

(In reply to katnatek from comment #51)
> (In reply to Philippe Didier from comment #48)
> > The worst bug to diagnose is the one that doesn't appear on all computers
> > We already found a first explanation thanks to Thomas :
> > we add Requires : binutils
> > 
> > The second explanation to find is : 
> > What explains the crash for you and for Thomas since he has installed
> > binutils ?
> > 
> > This crash doesn't appear for me even in a VM where I installed a basic
> > Mageia9
> > (see https://bugs.mageia.org/show_bug.cgi?id=32535#c41)
> > this crash doesn't appear for Jose Manual..
> Sorry the typo is "Jose Manuel"
> > 
> > I am still thinking about an hidden dependency for you and Thomas
> > 
> > about bug 32536 (similar to the old bug 29742) maybe it's possible to create
> > a conditional spec file !
> 
> I think this and 32536 is the same bug, but who knows 2 bugs with the same
> "solution" not sound weird to me anymore XD

Not all
 bug 29742 appeared only on 32bits in year 2021 and is similar to bug 32536 :
it was induced by the Mageia's build_flags
building directly from source didn't crash
Building directly with a modified buildd where the Mageia's build_flags had been added https://bugs.mageia.org/attachment.cgi?id=13054
induced a crash
https://bugs.mageia.org/show_bug.cgi?id=29742#c33

There's something that doesn't work anymore for i586 systems with Mageia's rpm

The solution is perhaps a spec file with something conditional like this

ifarch 1586
disable what you need
endif

bug 32535 appears for you and Thomas with the an other reason than the fader problem
that the rpm from updates_testing corrected, and for an other reason than the problem with 32 bits systems

That seems specific to both of you
The workaround doesn't allow to find where to dig to find what is the culprit 
I persist to think that a rpm is missing for you

(In reply to katnatek from comment #52)
> @Jani & Philippe , with the amount of warnings building this without ninja
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 9-x86_64/06671952-guayadeque/builder-live.log.gz (use the search function of
> your browser to go to 30% and start to scroll down) 

The next interesting points come until 44%, 51%, 64%, 78%, 79%, 85%, 86%, 87%

(In reply to Philippe Didier from comment #53)
> (In reply to katnatek from comment #51)
> > > I think this and 32536 is the same bug, but who knows 2 bugs with the same
> > "solution" not sound weird to me anymore XD
> 
> Not all
>  bug 29742 appeared only on 32bits in year 2021 and is similar to bug 32536 :
> it was induced by the Mageia's build_flags
> building directly from source didn't crash
> Building directly with a modified buildd where the Mageia's build_flags had
> been added https://bugs.mageia.org/attachment.cgi?id=13054
> induced a crash
> https://bugs.mageia.org/show_bug.cgi?id=29742#c33
> 
> There's something that doesn't work anymore for i586 systems with Mageia's
> rpm
> 
> The solution is perhaps a spec file with something conditional like this
> 
> ifarch 1586
> disable what you need
> endif
> 
> bug 32535 appears for you and Thomas with the an other reason than the fader
> problem
> that the rpm from updates_testing corrected, and for an other reason than
> the problem with 32 bits systems
> 
> That seems specific to both of you
> The workaround doesn't allow to find where to dig to find what is the
> culprit 
> I persist to think that a rpm is missing for you

The reason that make me thing is the same is the age of my 2 systems, I find information that the x86_64 (Dell Optiplex 755) and the i586 (Compaq Presario C700 Notebook, Model 30D9) are too close in age (mid 2007, and in a moment of 2008)

The main reason that make me doubt about missing require(s) is that nothing more were installed in my test disabling as needed so the missing require(s) must be still missing and thee application must fail also

(In reply to katnatek from comment #52)
> @Jani & Philippe , with the amount of warnings building this without ninja
> https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-
> 9-x86_64/06671952-guayadeque/builder-live.log.gz (use the search function of
> your browser to go to 30% and start to scroll down) I think could a bad use
> of a function or a missing include in somewhere, why crash for me and Thomas
> is beyond of my current abilities

this happens with or without ninja
All these warnings about deprecated declarations don't prevent to build and to work
They are known by the guayadeque developer and don't need absolutely to be corrected

I already created  patches for some of them and applied them but it doesn't bring anything better in the end.
No emergency to modify the source code

(In reply to katnatek from comment #55)
> (In reply to Philippe Didier from comment #53)

> The reason that make me thing is the same is the age of my 2 systems, I find
> information that the x86_64 (Dell Optiplex 755) and the i586 (Compaq
> Presario C700 Notebook, Model 30D9) are too close in age (mid 2007, and in a
> moment of 2008)
> 
> The main reason that make me doubt about missing require(s) is that nothing
> more were installed in my test disabling as needed so the missing require(s)
> must be still missing and thee application must fail also

You got the explanation !
You're certainly right it's a problem with the age of your systems
same age (2009) than the system for which I created bug 29742 (compaq mini 311)

That leads you now to bug 32536 : it's not a dependency problem !!!
and it's a flag problem !

If Thomas has an old system too we can close this

@ Thomas
Is your computer an old x86_64 ?
Some of them were not strictly compatible with 64bits programs !

If yes it's the bug 32536 for you too !!! and we may close this one...

(In reply to Philippe Didier from comment #58)
> @ Thomas
> Is your computer an old x86_64 ?
> Some of them were not strictly compatible with 64bits programs !
> 
> If yes it's the bug 32536 for you too !!! and we may close this one...

inxi -F 

provide some information also about the age (at less of the bios)

@Philippe

Remember I recommend this 2 lines, the second is enough but the first compensate any loss in the optimizations

%global optflags %{optflags} -flto=auto 
%global _disable_ld_as_needed 1

(In reply to Philippe Didier from comment #50)
> @ Jani
> You apparently applied this change only for Cauldron ?
> Do I need only to revert the release bump to Mageia9 ?

Release bump needs to be reverted in both, mga9 and cauldron.

(In reply to Jani Välimaa from comment #46)
> Removing '-Wl,--as-needed' linker flag is OK, if it's the last resort.
> However it's still a workaround until we figure out what's really causing
> the crash.
> 

Someone having a crash should install debug packages and run the app through gbd to get a backtrace. It might give some clues.

(In reply to Jani Välimaa from comment #61)
> (In reply to Philippe Didier from comment #50)
> > @ Jani
> > You apparently applied this change only for Cauldron ?
> > Do I need only to revert the release bump to Mageia9 ?
> 
> Release bump needs to be reverted in both, mga9 and cauldron.

Done for both of them now

(In reply to Philippe Didier from comment #57)
> (In reply to katnatek from comment #55)
> > (In reply to Philippe Didier from comment #53)
> 
> > The reason that make me thing is the same is the age of my 2 systems, I find
> > information that the x86_64 (Dell Optiplex 755) and the i586 (Compaq
> > Presario C700 Notebook, Model 30D9) are too close in age (mid 2007, and in a
> > moment of 2008)
> > 
> > The main reason that make me doubt about missing require(s) is that nothing
> > more were installed in my test disabling as needed so the missing require(s)
> > must be still missing and thee application must fail also
> 
> You got the explanation !
> You're certainly right it's a problem with the age of your systems
> same age (2009) than the system for which I created bug 29742 (compaq mini
> 311)
> 
> That leads you now to bug 32536 : it's not a dependency problem !!!
> and it's a flag problem !
> 
> If Thomas has an old system too we can close this

I looked at the specifications of the Dell Optiplex 755 :
the cache memory of some of the processors used for this computtr was very little

Perhaps an explanation for the stack overflow when using sqlite to build the database...

(In reply to Philippe Didier from comment #58)
> @ Thomas
> Is your computer an old x86_64 ?
> Some of them were not strictly compatible with 64bits programs !
> 
> If yes it's the bug 32536 for you too !!! and we may close this one...

Yes, the system in question is a Dell Dimension e520. It began life as a Dell Dimension e310, but just to see if it could be done I bought a motherboard and needed daughterboard on eBay that converted (with some case modifications) to the e520.

That model originally shipped with a 64-bit P4, but the motherboard I bought had had BIOS upgrades to use a Core2Quad Q6600. 

This is the first x86_64 application from Mageia that it has been unable to use, possibly because of its age.

(In reply to Thomas Andrews from comment #65)
> (In reply to Philippe Didier from comment #58)
> > @ Thomas
> > Is your computer an old x86_64 ?
> > Some of them were not strictly compatible with 64bits programs !
> > 
> > If yes it's the bug 32536 for you too !!! and we may close this one...
> 
> Yes, the system in question is a Dell Dimension e520. It began life as a
> Dell Dimension e310, but just to see if it could be done I bought a
> motherboard and needed daughterboard on eBay that converted (with some case
> modifications) to the e520.
> 
> That model originally shipped with a 64-bit P4, but the motherboard I bought
> had had BIOS upgrades to use a Core2Quad Q6600. 
> 
> This is the first x86_64 application from Mageia that it has been unable to
> use, possibly because of its age.

OK 
So, this is not a missing dependency... 
but maybe something related with the stack management with these old processors

I don't know if we must use what katnatek proposes :

%global optflags %{optflags} -flto=auto 
%global _disable_ld_as_needed 1

only to be compatible for these old 64bits processors

(nevertheless it may be useful to add this as a conditional pat in the spec files for i586 processors like bug 32536)

I hope we are at least circumscribing the reason of this particular bug that doesn't appear on other computers than Thomas'one and katnatek's one

A solution appeared for bug 32536 and may be good here too
May you test it with this rpm for Mageia9 64bits
https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm

https://bugs.mageia.org/show_bug.cgi?id=32536#c21

simply adding to the last spec file from Mageia svn
%global _disable_ld_as_needed 1
seems enough

We might resolve 4 bugs in one time !

LC_ALL=C urpmi https://download.copr.fedorainfracloud.org/results/katnatek/blogdrake/mageia-9-x86_64/06675361-guayadeque/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm


warning: /var/cache/urpmi/partial/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 20b7fd3d: NOKEY
The following package has bad signature:
/var/cache/urpmi/partial/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm: Invalid signature (NOT OK (no key): /var/cache/urpmi/partial/guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 20b7fd3d: NOKEY)
Do you want to continue installation ? (y/N) y
installing guayadeque-0.4.7-3.git20231115.1.1bdk_mga9.x86_64.rpm from /var/cache/urpmi/partial
Preparing...                     #################################################################
      1/1: guayadeque            #################################################################

Test on my Mageia 9 x86_64, Not surprise, can run without crash

Uninstalling waiting the official package

resolved by bug 32550

Resolution: (none) => FIXED
Status: NEW => RESOLVED