I've been pulling my hair out since Monday trying to get the newly revamped Beta code for my thesis project to run correctly on Linux. What I found was that GPGME 1.x wasn't working correctly because I didn't compile my code with Large File Support. I didn't even suspect something like this, until I read through the entire info page for GPGME and found a paragraph about the
off_t type being 32 bits unless LFS was on, then it was 64 bits.... oh, and by the way GPGME is compiled with LFS on by default and your application must be compiled with the same options to work correctly. Recompiling with LFS on fixed the issues I was having with GPGME 1.x on Linux.... and introduced another one related to
libtar. All I can say about this is "I now prefer FreeBSD to Linux".
I did some digging, and as far as I can tell,
libtar doesn't have LFS.... so I may have to implement with an alternative (
libarchive ). This makes me unhappy. It is the right way to go in the long run. Libarchive is fairly portable AND has LFS, libtar is portable with no LFS. But, in the short term my thesis isn't advancing.
Yeah... this is no good.
I tore through
libarchive this afternoon... I liked
libtar's API better from a user stanpoint, but
libarchive looked okay. The nail in the coffin is not being able to make the
libarchive example in the man page actually run. Well.... okay it ran but wouldn't create a TAR or terminate.
Glad libarchive didn't work out.
Trying another archiving library was something that did in "panic mode". I literally spent several hours trying to nail down the problem without prevailing. In this case I'm glad that libarchive didn't workout.... because after taking a break from coding for a 3 mile run I was able to chase down the problem. Heap corruption. Something that got changed trying to figure out the previous bug with GPGME. Undoing that change did the trick. Now to get the networking debugged....
My thesis project: one day it will work, just not today.
