| 1 |
Has anyone managed to get OFX support working in 64 bit? It seems that |
| 2 |
libtool is unable to create a loadable object for libofx, which prevents |
| 3 |
GnuCash from being able to load libgncmod-ofx. From what I've been able |
| 4 |
to gather, the reason libtool can't make a .so for libofx has something |
| 5 |
to do with libstdc++... when building libgncmod-ofx, I get the following |
| 6 |
error from libtool: |
| 7 |
|
| 8 |
*** Warning: linker path does not have real file for library -lstdc++. |
| 9 |
*** I have the capability to make that library automatically link in |
| 10 |
when |
| 11 |
*** you link to this library. But I can only do this if you have a |
| 12 |
*** shared version of the library, which you do not appear to have |
| 13 |
*** because I did check the linker path looking for a file starting |
| 14 |
*** with libstdc++ and none of the candidates passed a file format test |
| 15 |
*** using a file magic. Last file checked: libstdc++.so.5.0.6 |
| 16 |
|
| 17 |
*** Warning: libtool could not satisfy all declared inter-library |
| 18 |
*** dependencies of module libgncmod-ofx. Therefore, libtool will |
| 19 |
create |
| 20 |
*** a static module, that should work as long as the dlopening |
| 21 |
*** application is linked with the -dlopen flag. |
| 22 |
|
| 23 |
Is there a way to fix this without adding -dlopen to LDFLAGS? I'd prefer |
| 24 |
to fix the root cause rather than the symptoms. And I'm avoiding |
| 25 |
learning the voodoo of libtool until someone pays me to do it;) |
| 26 |
-- |
| 27 |
Gregory Symons |
| 28 |
Software Engineer |
| 29 |
|
| 30 |
GPG Public Key available at http://www.gsconsulting.biz/PGP/gsymons.asc |
Archives