On Wed, 12 Aug 2015 18:03:57 -0600, Zan Lynx wrote: > On 08/12/2015 04:01 PM, Holger Hoffstätte wrote: >> >> It gets weirder.. >> >> On Wed, 12 Aug 2015 21:43:08 +0000, Holger Hoffstätte wrote: >> >>> On startup it can somehow no longer properly locate the ~/.pan2 >>> directory and always decides to create an empty newsrc-1 in my ~. >> >> Actually it creates the newsrc-1 in the $CWD. Apparently the newly >> built binary (using it right now) works fine when I start it in the >> ~/.pan2 directory, where it can find the old newsrc and all settings. >> Why the old version works without any $CWD (from an xfce launcher) >> remains a mystery for now. >> >> Suggestions welcome.. > > From a quick peek at the source code I don't see how it could be a > problem with libstdc++. Instead I'd look for problems with glib. > Specifically g_get_home_dir() and g_build_filename().
Interesting! Thanks for looking into this. I hadn't looked at the source yet. My first suspicion was a C++ dependency that needed rebuilding as well (gtkmm or the like), but pan has none and in that case I'd expect real breakage due to the std::string ABI changes anyway. > Maybe your pan linked to the wrong version of glib somehow? Nope, only one installed and if there was something wrong with that I'd have noticed already. > Or it could be a faulty assumption that the char* returned remains > valid. Most places in the code assign to a std::string which makes a > copy and is great. Other places assign to a char* and I am not sure that > the pointed-to value remains valid. > > I checked and the glib docs say g_getenv()'s value remains valid only > until the next call to a list of functions. > > A change in how GCC compiles could be responsible for causing a > temporary pointer to get overwritten which didn't happen with an older > compiler. That doesn't sound impossible (though horrible), but since I got the same effect after rebuilding with clang I suspected the stdlib first. The fact that the old binary worked fine certainly points to a (common) change in compile-time behaviour and maybe std::string lifetime handling. Seems like the change in _GLIBCXX_USE_CXX11_ABI deserves a closer look. > Or maybe you did something like export PAN_HOME without setting it. > Because I see in the code that PAN_HOME overrides everything else, and > it doesn't seem to check it for being blank. Checked that too - PAN_HOME isn't ever set. For now I simply set the CWD to ~/.pan2 in the launcher and things work fine, just as before. Maybe I'll strace/debug further on the weekend. Thanks again! Holger _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
