From: Benoit G. <be...@co...> - 2011-04-13 21:56:20
|
LibOFX 0.9.3: - Fix segfault on some files containing missing closing tags (bug #2969817) - Note to packagers: Upstream has moved to git at git://libofx.git.sourceforge.net/gitroot/libofx/libofx -- Benoit Grégoire, ing., PMP, PSM |
From: Gérald N. <ger...@ge...> - 2011-04-14 07:10:11
|
Hi Benoit, Le 13 avr. 2011 à 23:56, Benoit Grégoire a écrit : > LibOFX 0.9.3: > - Fix segfault on some files containing missing closing tags (bug #2969817) > - Note to packagers: Upstream has moved to git at git://libofx.git.sourceforge.net/gitroot/libofx/libofx i will tell you my issue in french, because my english is so worth to explain this correctly. Je suis le mainteneur des paquets binaires de Grisbi pour Mac OSX. Grisbi est basé sur GTK et utilise libofx pour l'import OFX. Les applications Mac OS X sont distribuées sous la forme de bundle contenant tout ce qui est nécessaire à l'exécution du programme. Le chemin de recherche des DTD semble fixé "en dur" au moment de la compilation. Du coup l'import OFX ne fonctionne pas car les DTD ne sont pas trouvées à l'exécution. J'ai contourné le problème en installant les DTD hors du bundle dans un répértoire fixé à la compilation. Mais le plus simple serait quand même de pouvoir tout distribuer dans le bundle. Serait-il possible de passer par une variable d'environnement ? Nous avons aussi un problème sous Windows, il est peut-être lié. Merci. -- Gérald Niel ger...@ge... |
From: Benoit G. <be...@co...> - 2011-04-14 20:21:32
|
> Je suis le mainteneur des paquets binaires de Grisbi pour Mac OSX. Grisbi > est basé sur GTK et utilise libofx pour l'import OFX. Les applications Mac > OS X sont distribuées sous la forme de bundle contenant tout ce qui est > nécessaire à l'exécution du programme. Le chemin de recherche des DTD > semble fixé "en dur" au moment de la compilation. Du coup l'import OFX ne > fonctionne pas car les DTD ne sont pas trouvées à l'exécution. J'ai > contourné le problème en installant les DTD hors du bundle dans un > répértoire fixé à la compilation. Mais le plus simple serait quand même de > pouvoir tout distribuer dans le bundle. Serait-il possible de passer par > une variable d'environnement ? Nous avons aussi un problème sous Windows, > il est peut-être lié. C'est fait (Libofx will now look for DTDs in env variable OFX_DTD_PATH (if present). Pouvez-vous tester la dernière version de git? git clone git://libofx.git.sourceforge.net/gitroot/libofx/libofx Je suis en train d'essayer de régler tous les problèmes des mainteneurs comme vous. Dès que ce sera terminé, je publierai un 0.9.4. -- Benoit Grégoire, ing., PMP, PSM |
From: Gérald N. <ger...@ge...> - 2011-04-15 07:01:18
|
Bonjour, Le 14 avr. 2011 à 22:21, Benoit Grégoire a écrit : > C'est fait (Libofx will now look for DTDs in env variable OFX_DTD_PATH (if present). Pouvez-vous tester la dernière version de git? Pour l'instant ça ne compile pas (le répértoire /Users/gerald/gtk/inst sert ensuite à la construction du bundle) : Making all in ofx2qif gcc -DHAVE_CONFIG_H -I. -I.. -I../inc -I/Users/gerald/gtk/inst/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -MT ofx2qif.o -MD -MP -MF .deps/ofx2qif.Tpo -c -o ofx2qif.o ofx2qif.c mv -f .deps/ofx2qif.Tpo .deps/ofx2qif.Po /bin/sh ../libtool --tag=CC --mode=link gcc -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -L/Users/gerald/gtk/inst/lib -L/Users/gerald/gtk/inst/lib -arch i386 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -Wl,-headerpad_max_install_names -o ofx2qif ofx2qif.o ../lib/libofx.la libtool: link: gcc -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -Wl,-headerpad_max_install_names -o .libs/ofx2qif ofx2qif.o -L/Users/gerald/gtk/inst/lib -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib ../lib/.libs/libofx.dylib -L/Users/gerald/gtk/inst/include /Users/gerald/gtk/inst/lib/libosp.dylib -lpthread /Users/gerald/gtk/inst/lib/libiconv.dylib -lstdc++ Making all in ofxdump make[2]: *** No rule to make target `cmdline.c', needed by `cmdline.o'. Stop. make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 @+ -- Gérald Niel ger...@ge... |
From: William O. <gun...@gm...> - 2011-04-15 07:18:51
|
Salut Gérald, J'ai eu le même problème sous Windows. Pour que la compilation se passe bien, il faut compiler et installer gengetopt avant, puis refaire un ./configure. Lors du make, gengetopt génère des fichiers sources nécessaires à la compilation des outils en ligne de commande. gengetopt se trouve à cette adresse : http://www.gnu.org/software/gengetopt/gengetopt.html Will @Gérald : Désolé pour le spam, j'avais oublié de faire répondre à tous... Le 15 avril 2011 09:01, Gérald Niel <ger...@ge...> a écrit : > Bonjour, > > Le 14 avr. 2011 à 22:21, Benoit Grégoire a écrit : > >> C'est fait (Libofx will now look for DTDs in env variable OFX_DTD_PATH (if present). Pouvez-vous tester la dernière version de git? > > Pour l'instant ça ne compile pas (le répértoire /Users/gerald/gtk/inst sert ensuite à la construction du bundle) : > > Making all in ofx2qif > gcc -DHAVE_CONFIG_H -I. -I.. -I../inc -I/Users/gerald/gtk/inst/include -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -MT ofx2qif.o -MD -MP -MF .deps/ofx2qif.Tpo -c -o ofx2qif.o ofx2qif.c > mv -f .deps/ofx2qif.Tpo .deps/ofx2qif.Po > /bin/sh ../libtool --tag=CC --mode=link gcc -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -L/Users/gerald/gtk/inst/lib -L/Users/gerald/gtk/inst/lib -arch i386 -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -Wl,-headerpad_max_install_names -o ofx2qif ofx2qif.o ../lib/libofx.la > libtool: link: gcc -arch i386 -I/Developer/SDKs/MacOSX10.5.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5 -Wl,-headerpad_max_install_names -o .libs/ofx2qif ofx2qif.o -L/Users/gerald/gtk/inst/lib -L/Developer/SDKs/MacOSX10.5.sdk/usr/lib ../lib/.libs/libofx.dylib -L/Users/gerald/gtk/inst/include /Users/gerald/gtk/inst/lib/libosp.dylib -lpthread /Users/gerald/gtk/inst/lib/libiconv.dylib -lstdc++ > Making all in ofxdump > make[2]: *** No rule to make target `cmdline.c', needed by `cmdline.o'. Stop. > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > > @+ > -- > Gérald Niel > ger...@ge... > > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Libofx-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libofx-devel > |
From: Gérald N. <ger...@ge...> - 2011-04-15 07:51:08
|
Bonjour William, Le 15 avr. 2011 à 09:18, William Ollivier a écrit : > Salut Gérald, > > J'ai eu le même problème sous Windows. > Pour que la compilation se passe bien, il faut compiler et installer > gengetopt avant, puis refaire un ./configure. Super ! ça compile bien maintenant, et pourvu que je définisse la variable OFX_DTD_PATH dans le script de lancement du bundle ça fonctionne bien. Parfait, merci. -- Gérald Niel ger...@ge... |
From: Gérald N. <ger...@ge...> - 2011-04-15 09:56:56
|
Le 15 avr. 2011 à 09:50, Gérald Niel a écrit : > Bonjour William, > > Le 15 avr. 2011 à 09:18, William Ollivier a écrit : > >> Salut Gérald, >> >> J'ai eu le même problème sous Windows. >> Pour que la compilation se passe bien, il faut compiler et installer >> gengetopt avant, puis refaire un ./configure. > > > Super ! ça compile bien maintenant, et pourvu que je définisse la variable OFX_DTD_PATH dans le script de lancement du bundle ça fonctionne bien. Ah bah non... ça ne fonctionne pas. @+ -- Gérald Niel ger...@ge... |
From: Benoit G. <be...@co...> - 2011-04-15 17:20:27
|
> > Super ! ça compile bien maintenant, et pourvu que je définisse la > > variable OFX_DTD_PATH dans le script de lancement du bundle ça > > fonctionne bien. > > Ah bah non... ça ne fonctionne pas. Ne trouve pas le DTD, ou ne fonctionne pas du tout? -- Benoit Grégoire, ing., PMP, PSM |
From: Gérald N. <ge...@gr...> - 2011-04-16 07:30:57
|
Bonjour, Le 15 avr. 2011 à 19:20, Benoit Grégoire a écrit : > Ne trouve pas le DTD, ou ne fonctionne pas du tout? Ne trouve pas le DTD. Mais je ne sais pas si ça vient du bundle ou non. Il existe une méthode pour tester en ligne de commande ? @+ -- Gérald Niel ger...@ge... |
From: Benoit G. <be...@co...> - 2011-04-16 17:18:13
|
On April 16, 2011 03:14:38 AM Gérald Niel wrote: > Bonjour, > > Le 15 avr. 2011 à 19:20, Benoit Grégoire a écrit : > > Ne trouve pas le DTD, ou ne fonctionne pas du tout? git pull et ressayez. Milles excuses, j'ai pousse un mauvais revert par erreur. > Ne trouve pas le DTD. Mais je ne sais pas si ça vient du bundle ou non. > Il existe une méthode pour tester en ligne de commande ? ofxdump --msg_debug Dans la sortie, cherche pour la chaine find_dtd(). Il te dira ou il a cherche. Devrait pouvoir se faire directement avec la commande: ofxdump --msg_debug /home/benoitg/tmp/releve.qfx 2>&1 | grep find_dtd Tu devrais voir une ligne avec OFX_DTD_PATH si la variable d'environnement etait presente. -- Benoit Grégoire, ing., PMP, PSM |
From: Gérald N. <ge...@gr...> - 2011-04-16 17:46:24
|
Bonsoir, Le 16 avr. 2011 à 19:18, Benoit Grégoire a écrit : > git pull et ressayez. Milles excuses, j'ai pousse un mauvais revert par > erreur. C'est parfait. Ça fonctionne comme il faut maintenant. Merci. -- Gérald Niel ger...@ge... |