[grisbi-devel] Grisbi 2.0 pour bientôt ?

[Ludovic Rousseau]

Le ven. 8 janv. 2021 à 13:51, Pierre <pierre at pierre.biava.name> a écrit :

> Le 07/01/2021 à 10:10, Ludovic Rousseau a écrit :
> > Le mer. 6 janv. 2021 à 23:35, Nicolas LAURENT <nl at haplo.info
> > <mailto:nl at haplo.info>> a écrit :
> >
> >     hello
> >
> >     mince je me suis loupé dans la doc. Pour meson, il s'agit d'un
> >     module python. J'ai fini par faire un "pip install meson".
> >
> >
> > De mon côté je l'ai installé avec Homebrew pour pouvoir continuer.
> > J'ai donc un environnement jhbuild à jour. Mais j'ai toujours le crash
> > sur Big Sur alors que "ça marche" sur Mojave.
> >
> > Je suspecte aussi un problème de pointeur.
> > Sur Big Sur dans le debugger j'ai :
> > * thread #1, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x80)
> >      frame #0: 0x0000000109e29e40
> > libgoffice-0.10.10.dylib`gog_plot_clear_series + 16
> > libgoffice-0.10.10.dylib`gog_plot_clear_series:
>
> On utilise deux fois cette fonction dans grisbi. Il se peut que le
> paramètre de cette fonction soit mal initialisé.
>
> Peux-t-on avoir plus d'explication sur ce message ?
>

Je crois que j'ai trouvé la cause du problème.
Le problème n'est pas du tout l'OS Mojave, Catalina ou Big Sur.
En fait les graphiques n'ont jamais (depuis que je génère les binaires)
fonctionné ailleurs que sur ma machine. Je ne crois pas avoir vu un rapport
de bug la dessus donc je me demande si c'est une feature utilisée.

goffice cherche ses plugins dans
/Users/rousseau/gtk/inst/lib/goffice/0.10.49/plugins/

C'est codé en dur dans la lib libgoffice-0.10.10.dylib :
$ strings libgoffice-0.10.10.dylib | grep inst
/Users/rousseau/gtk/inst/share/goffice/0.10.49
/Users/rousseau/gtk/inst/share/pixmaps/goffice/0.10.49
/Users/rousseau/gtk/inst/lib/goffice/0.10.49
/Users/rousseau/gtk/inst/lib/goffice/0.10/plugins
/Users/rousseau/gtk/inst/share/locale

C'est très con parce que ce chemin n'existe *que* sur ma machine.

Nicolas, ton binaire lui utilise un autre chemin :
/Users/nl/gtk/inst/lib/goffice/0.10.49

Ton binaire fonctionne très bien chez toi mais pas chez moi (et
réciproquement)
Par contre si tu déplaces le dossier ~/gtk alors tu auras aussi le plantage.
C'est pour ça que je t'avais demandé de tester ton binaire sur une autre
installation de Big Sur. Je me doutais que Grisbi utilisait des fichiers
présents uniquement sur la machine ou le compte de dev.

Un autre problème est que les binaires des plugins n'utilisent pas
@executable_path/ mais un chemin en dur aussi.
$ otool -L
/Volumes/Grisbi/Grisbi.app/Contents/Resources/Grisbi.app/Contents/Resources/lib/goffice/0.10.49/plugins/plot_barcol/barcol.so

/Volumes/Grisbi/Grisbi.app/Contents/Resources/Grisbi.app/Contents/Resources/lib/goffice/0.10.49/plugins/plot_barcol/barcol.so:
/Users/nl/gtk/inst/lib/libgoffice-0.10.10.dylib (compatibility version
11.0.0, current version 11.49.0)
[...]

J'ai modifié les scripts de génération pour appeler gtk-mac-bundler sur les
plugins mais ça ne résous qu'une partie du problème.

J'ai regardé le code source de goffice. C'est pas prévu d'avoir un chemin
calculé à l'exécution.
https://github.com/GNOME/goffice/blob/master/goffice/goffice.c#L53

Le problème est donc dans goffice qui n'est pas embarquable dans un binaire
sur macOS.
On peut surement configurer goffice pour qu'il cherche les plugins dans
/Applications/Grisbi.app/... mais c'est crade et ça ne fonctionne QUE si
Grisbi se trouve dans le dossier /Applications/
Je n'utilse (quasiment) jamais les graphiques de Grisbi. Je ne crois pas
que je vais faire l'effort de corriger le problème dans goffice.

Je propose de désactiver goffice et les graphiques dans Grisbi sur macOS.
Sauf si quelqu'un propose une solution.

à+

-- 
 Dr. Ludovic Rousseau
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listes.grisbi.org/pipermail/devel/attachments/20210108/c0c860c4/attachment.html>