[GNC-dev] Resolving symlinks in _br_find_exe in binreloc.c

[Mike Alexander]

On 21 May 2020, at 14:41, John Ralls wrote:

> The code that we have is gnomified from the original autopackage.org 
> version. I agree it's pretty awful; the comparison of sizeof(ptr) to 
> SSIZE_MAX particularly so; trying to allocate SSIZE_MAX-1 in the 
> impossible case that sizeof(ptr) > SSIZE_MAX borders on comical. I 
> suggest that rather than allocating the path buffers you just create 
> two char[PATH_MAX +1] buffers on the stack.

Yes, I noticed those glaring errors.

> There's another problem though, /proc/self/exe is Linux-only so it 
> still won't work for the BSDs. They don't all have proc (OpenBSD 
> doesn't, it's optional on FreeBSD; NetBSD has procfs and uses 
> /proc/curproc/exe; DragonFly BSD uses /proc/curproc/file [1]). The 
> most general solution is to store argv[0] in inner_main and then look 
> for that file in $PATH. I dunno if it's that prominent a use case. 
> There have been only 2 bugs about binreloc ever and neither of them is 
> that it doesn't work.

If /proc/self/exe doesn't lead anywhere useful it falls back to reading 
from /proc/self/maps.  Is that any better?  Or is it even worth doing?  
It sounds like it isn't likely to succeed.  Too bad there isn't a 
general way to deal with this.

I started down this rabbit hole because running the Mac build of GnuCash 
from the build directory fails without this fix.  I'll try to make it 
work at least in MacOS.

While looking for a general way to do this I found this StackOverflow 
thread:

https://stackoverflow.com/questions/1528298/get-path-of-executable/1528493

This is the most complete discussion of this problem that I found.  It 
contains a link to 
https://svn.sullivanandkey.com/SnKOpen/cpp/executable_path/trunk/ which 
seems to be a remarkably complete solution to this problem.  It is 
probably overkill for GnuCash, but it is interesting.  I'll probably 
just make the existing code work right and leave it at that.  Is that ok 
with you, or should I try to use this more general solution?  Since 
GnuCash already uses Boost and CMake it might not be too hard to do.

          Mike