Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
GetAppPath vs. DetermineExecutablePath
thomas:
Well, the most interesting bit (I think) is the 5 lines of code around readlink("/proc/self/exe") or realname, respectively. :)
If other Unix-derivates support /proc/self too, that's even better. I used the strict __linux__ instead of something more relaxed because I thougth it was a proprietary Linux feature. But actually there is no harm if we always use it, as realname will return 0 if the given location does not exist, so it is perfectly safe to just try and see if we get back a valid pointer.
Another possibility to get the install dir would be popen("which codeblocks"), but that's a lot slower than reading /proc/self, and unreliable, too (so we should probably abstain from it).
EDIT:
Btw, you said "proc hack". The proc hack is really not a hack at all, it is the one perfectly legal way of doing it. That's what proc is for, after all :)
afb:
--- Quote from: thomas on November 21, 2006, 01:32:22 pm ---Well, the most interesting bit (I think) is the 5 lines of code around readlink("/proc/self/exe") or realname, respectively. :)
--- End quote ---
Yup. BinReloc says that doesn't work for libraries, but we don't care I guess.
--- Quote ---If other Unix-derivates support /proc/self too, that's even better. I used the strict __linux__ instead of something more relaxed because I thougth it was a proprietary Linux feature.
--- End quote ---
Apparently /proc is not mounted on FreeBSD, so it's not really useful there.
--- Quote ---EDIT:
Btw, you said "proc hack". The proc hack is really not a hack at all, it is the one perfectly legal way of doing it. That's what proc is for, after all :)
--- End quote ---
Fair enough. I just think that fiddling around with /proc/self/exe is ugly :-)
(not the solution itself, but the need to use it in application level code...)
It's not like we really need the application path for anything as it is,
except messing around with finding the datadir and plugins relative to it...
mandrav:
--- Quote from: afb ---It's not like we really need the application path for anything as it is,
except messing around with finding the datadir and plugins relative to it...
--- End quote ---
Does this seem to be a minor/non-important task?
afb:
--- Quote from: mandrav on November 21, 2006, 03:17:07 pm ---
--- Quote from: afb ---It's not like we really need the application path for anything as it is,
except messing around with finding the datadir and plugins relative to it...
--- End quote ---
Does this seem to be a minor/non-important task?
--- End quote ---
What I meant was that if we don't need it for that task, we don't need it at all ?
So it doesn't matter much if it fails on FreeBSD, since it finds the files by prefix ?
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...)
mandrav:
--- 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?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version