[GNC-dev] Resolving symlinks in _br_find_exe in binreloc.c
mta at umich.edu
Fri May 22 01:39:27 EDT 2020
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 ). The
> most general solution is to store argv 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
This is the most complete discussion of this problem that I found. It
contains a link to
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.
More information about the gnucash-devel