When trying to compile gnucash, I get a problem when trying to build libofx.. probably a multilib toolchain problem or a libtool bug.. And I get the following message: *** Warning: linker path does not have real file for library -lstdc++. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libstdc++ and none of the candidates passed a file format test *** using a file magic. Last file checked: libstdc++.so.5.0.6 *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libgncmod-ofx. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. btw libstdc++.so.5.0.6 is in /usr/lib64/libstdc++-v3/ and append-ldflags -L/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/ allows it to build properly (even though its not the right fix).. Seemant, since /usr/X11R6 is now a symlink, it will spit tons of warnings if we dont do this: [ -L "/usr/X11R6" ] || append-ldflags -L/usr/X11R6/$(get_libdir)
Olivier, could it be that you hit the gcc-bug? does /usr/lib64/libstdc++-v3 show up in /etc/ld.so.cache?
Tester, please respond?
Created attachment 63839 [details, diff] fix building of ofx plugin I found the problem.. .. For some reason, it does not work if -lstdc++ is passed directly, but it works correctly if we remove it and let libtool do its job... the patch is attached..
Created attachment 63840 [details, diff] ebuild patch
Seemant, I think this is yours.. I dont see how it would be amd64 specific..
The ebuild and patch fixed my problems with libofx working correctly within gnucash
guys, I'm not seeing this issue at all with libofx-0.8.0 -- I'm about to test with 0.7.0, but surely there's something going on if it's only happening to a few people. The thing is, what?
I had this problem with libofx-0.8. Please see below viper ~ # emerge -s gnucash libofx Searching... [ Results for search key : gnucash ] [ Applications found : 1 ] * app-office/gnucash Latest version available: 1.8.11 Latest version installed: 1.8.11 Size of downloaded files: 9,280 kB Homepage: http://www.gnucash.org/ Description: A personal finance manager License: GPL-2 Searching... [ Results for search key : libofx ] [ Applications found : 1 ] * dev-libs/libofx Latest version available: 0.8.0 Latest version installed: 0.8.0 Size of downloaded files: 730 kB Homepage: http://libofx.sourceforge.net/ Description: Library to support the Open Financial eXchange XML Format License: GPL-2
I have a very similar error only with gwrap-glib I see the warning: *** Warning: linker path does not have real file for library -lgwrap-glib. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** beca*** Warning: linker path does not have real file for library -lgwrap-glib. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have *** because I did check the linker path looking for a file starting *** with libgwrap-glib but no candidates were found. (...for file magic test) *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libgw-core-utils. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. use I did check the linker path looking for a file starting *** with libgwrap-glib but no candidates were found. (...for file magic test) *** Warning: libtool could not satisfy all declared inter-library *** dependencies of module libgw-core-utils. Therefore, libtool will create *** a static module, that should work as long as the dlopening *** application is linked with the -dlopen flag. And *** Warning: This system can not link to static lib archive libgncmodule.la. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** But as you try to build a module library, libtool will still create *** a static module, that should work as long as the dlopening application *** is linked with the -dlopen flag to resolve symbols at runtime. And eventually error out with: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lgwrap-glib
I solved the problem I reportec by re-emerging g-wrap. Fotunately found that info on the forums from 2002.
apparently a remerge of g-wrap fixes this.
