Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
GetAppPath vs. DetermineExecutablePath
afb:
Neat that BinReloc is working for FreeBSD, I know that it doesn't for Mac OS X.
Maybe we should start with using BinReloc if available (#ifdef ENABLE_BINRELOC),
and then fall back to Thomas solution for Linux and my own solution for Darwin ?
edit: Or maybe ENABLE_BINRELOC wasn't the definition to use, on second glance
that looks more like a setting to whether use binary relocation or use APP_PREFIX...
mandrav:
--- Quote from: afb on November 21, 2006, 03:47:43 pm ---edit: Or maybe ENABLE_BINRELOC wasn't the definition to use, on second glance
that looks more like a setting to whether use binary relocation or use APP_PREFIX...
--- End quote ---
#ifdef SELFPATH
thomas:
--- Quote from: mandrav on November 21, 2006, 03:37:48 pm ---
--- Quote ---Do you think we should lose using the BinReloc library, as Thomas suggests above ?
(his implementation is a fair bit shorter than what prefix.cpp and prefix.h are...)
--- End quote ---
binreloc is working under many unix implementations (including freebsd) while Thomas' solution only works for linux if I understood correctly?
--- End quote ---
There is no big magic in "many unix implementations". Binreloc returns a "hardcoded path" when /proc/self does not work, according to its documentation. That's what my implementation does too. In fact, "hardcoded path" means ".", because that's all you can really do if /proc fails. This is a hack which fails under many circumstances.
Remember, Unix offers no way to determine a file's location or name from its inode (or an application's location from its image) as there may be an arbitrary number hard links (and those may even be added and removed while the program is running). /proc/self is a notable exception because it points to the FS entry that was used to launch the executable.
afb:
/proc is indeed empty on FreeBSD (at least on FreeBSD 6.1). So I don't see how BinReloc can "work" there either ? It does have a /usr/compat/linux/proc/self/exe, but that's probably not part of the core...
So since we need special cases for Windows, Mac OS X, FreeBSD, Solaris - I guess that means that the "many unix implementations" are probably the same as Linux in practice anyway ? :)
thomas:
Probably :)
The question is what to make of it, though. We can always try to read /proc/self, there is no harm -- if it fails, we know it. However, if it fails, we have to use something else.
We could use ".", that works in many cases, but does not work in many other cases. We could hardcode some platform-dependent path like /usr/local/bin, but that does not work in all cases, either. We could use the prefix given by ./configure's --prefix, but that still does not work in all cases.
The problem with hardcoding an absolute path is that Code::Blocks will be bound to that one location. Unluckily, "." is not much better, it works in arbitrary locations, but depends on the mode of execution... :(
What to do?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version