how long does gnucash remember --with-ofx-prefix=/opt/libofx?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

how long does gnucash remember --with-ofx-prefix=/opt/libofx?

David Reiser
I've built last weekend's g2 version (11850) several times trying to  
see if I can resolve problems with ofx. Basically, it isn't working  
at all for me. Initially it complains that it can't find the leading  
'<' character. If I delete the ofx file preamble so that the file  
starts with '<ofx>', then it complains of a premature end of file at  
'</ofx>'.

The reason for the subject line is that I have the fink version of  
libofx 0.7.0 installed in the normal location in the /sw tree. I also  
built the CVS version of libofx 0.8.0 in /opt/libofx in hopes of  
trying out ofxdirectconnect. (gwenhywfar won't build, so I can't even  
try getting aqbanking up)

Anyway, since version 0.7.0 is in my PATH (and very early  
therein...), and 0.8.0 is not in my PATH, will Gnucash, once it is  
built, remember where I told configure the newest libofx is, or not?

--
David Reiser
[hidden email]

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: how long does gnucash remember --with-ofx-prefix=/opt/libofx?

Christian Stimming
Am Sonntag, 13. November 2005 03:45 schrieb David Reiser:
> I've built last weekend's g2 version (11850) several times trying to
> see if I can resolve problems with ofx. Basically, it isn't working
> at all for me. Initially it complains that it can't find the leading
> '<' character. If I delete the ofx file preamble so that the file
> starts with '<ofx>', then it complains of a premature end of file at
> '</ofx>'.

Probably a problem that should be discussed on the libofx developer list...

> The reason for the subject line is that I have the fink version of
> libofx 0.7.0 installed in the normal location in the /sw tree. I also
> built the CVS version of libofx 0.8.0 in /opt/libofx in hopes of
> trying out ofxdirectconnect.

Yes, this is the exact setup where --with-ofx-prefix should be your solution.
If you're not sure whether the directory from there is really picked up
correctly, then look for the lines containing LIBOFX_CFLAGS and LIBOFX_LIBS
in the top-level file ./config.status. In your case they should probably read

s,@LIBOFX_CFLAGS@,-I/opt/libofx/include,;t t
s,@LIBOFX_LIBS@, -L/opt/libofx/lib -lofx,;t t

so that the include directory and the library directory are both specified
here. If they are not, then ./configure for whatever reason unfortunately
didn't pick up correctly your --with-ofx-prefix. As a whacky workaround you
can (after running ./configure) edit these lines in ./config.status and
run ./config.status after that. However, you will need to repeat that each
time ./configure has been run. Of course in the long run we need to fix the
detection of libofx in ./configure, but this workaround should be a solution
for you for now.

> (gwenhywfar won't build, so I can't even
> try getting aqbanking up)

gwenhywfar doesn't build? Not even the most recent gwenhywfar-1.19.1? I and
Martin Preuss would happily try to fix this. You can send the build errors to
me privately and we'll see what we can do.

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: mac osx and gwenhywfar build (re: how long does gnucash remember --with-ofx-prefix=/opt/libofx?)

Christian Stimming
Hi David,

thanks for pointing out this build problem.

David Reiser schrieb:

>>> (gwenhywfar won't build, so I can't even try getting aqbanking up)
>>
>> gwenhywfar doesn't build? Not even the most recent  gwenhywfar-1.19.1?
>> I and Martin Preuss would happily try to fix this.
>
> Making all in test
> if gcc -DHAVE_CONFIG_H -I. -I. -I..   -I/sw/include  -I/sw/include
> -Wall -MT gwentest.o -MD -MP -MF ".deps/gwentest.Tpo" -c -o gwentest.o  
> gwentest.c; \
> then mv -f ".deps/gwentest.Tpo" ".deps/gwentest.Po"; else rm -f  
> ".deps/gwentest.Tpo"; exit 1; fi
> /bin/sh ../libtool --tag=CC --mode=link gcc  -I/sw/include -Wall  
> -Lsw/lib -o gwentest  gwentest.o -L../src -lgwenhywfar -L../gwenui -lgwenui
> mkdir .libs
> gcc -I/sw/include -Wall -o gwentest gwentest.o  -L/sw/lib -L/Users/
> dbr/Desktop/gwenhywfar-1.19.1/src /sw/lib/libgwenhywfar.dylib -lssl
> -lcrypto -L/Users/dbr/Desktop/gwenhywfar-1.19.1/gwenui /sw/lib/
> libgwenui.dylib /sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lpanel
> -lncurses
> /usr/bin/ld: Undefined symbols:
> _GWEN_CryptToken_PinEncoding_fromString

Well, the error comes when the included test program is built, so the
library already built correctly.

The linker errors mean that the linker tries to link the (new) test
program against an existing (old) libgwenhywfar which resides in the
directory that is first specified with -L..., i.e. in /sw/lib. The
problem here is that you have been told to set LDFLAGS=-L/sw/lib , so
/sw/lib is forced to be searched first, even before the directory ../src
which would pick up the new library. Hm...

A permanent solution is not so easy. A simple workaround for you is: if
you get this error, then hand-edit test/Makefile, look for the string
"-L/sw/lib" and simply delete that string everywhere you find it in this
makefile. Then run make again and everything should build.

Another workaround is to remove/rename the existing
/sw/lib/libgwenhywfar, but we would ask you to test something else
beforehand: Can you try something that might permanently fix this
problem? In the file configure.ac, edit the line 247 which currently reads

           all_libraries="${all_libraries} -lintl"

so that it reads instead

           all_libraries="-L/sw/lib ${all_libraries} -lintl"

and then run "make" again. I hope that all build tools are available so
that ./configure and all Makefiles will be rebuilt correctly.  Then run
./configure again but without the LDFLAGS setting, i.e. make sure that
LDFLAGS is empty.

If the build system rebuild fails with some mysterious error messages
from some weird auto*** program, then as a last resort you can untar the
gwenhywfar tarball again, edit the file ./configure and look for the
original line mentioned above (in my case this is line number 24015 but
this might be different for you), edit it accordingly, and run
./configure again.

If this change works for you then we know how to fix it in the next release.

Regards

Christian
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel