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

[Geert Janssens]

I remember having some discussion about this in the past (I believe on irc) about binreloc and a 
potential c++ replacement. Perhaps it's one of the links in the SO you refer to, I don't 
remember exactly.

One of the issues with binreloc is it doesn't work well for our bindings (python & guile) because 
it is based on the location of the running executable. In case of the python bindings that is 
python, not our gnucash executable.

The alternative is to start from the library that executes the relocation detection and that was 
what the solution I ran into back then did.

I mention this just in case you do change your mind and decide to work on a complete rewrite 
after all. If not, I'm fine with you just fixing it for your use case.

Regards,

Geert

Op vrijdag 22 mei 2020 07:39:27 CEST schreef 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
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel