Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
GetAppPath vs. DetermineExecutablePath
mandrav:
--- 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.
--- End quote ---
We do have *BSD users and it does work for them. Heck, we had even got a patch for binreloc to work on *BSD.
Admittedly, I have not looked into binreloc's code but it was safe to assume that it works, since *BSD users were saying so?
--- Quote ---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.
--- End quote ---
Hardcoding is out of the question.
Why, all of the sudden, do you want to change things regarding this matter? It does work as it is anyway, AFAIK. And if there are cases which don't work and there is no OS-provided workaround available, C::B already allows you to set the data path in two distinct ways: 1) by adding a command-line option or 2) by setting an environment variable.
The bottom line is that C::B, most of the times, will determine its path automatically but if it doesn't it can be directed to it by the user.
afb:
--- Quote from: mandrav on November 22, 2006, 09:37:51 am ---
--- 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.
--- End quote ---
We do have *BSD users and it does work for them. Heck, we had even got a patch for binreloc to work on *BSD.
Admittedly, I have not looked into binreloc's code but it was safe to assume that it works, since *BSD users were saying so?
--- End quote ---
I think the patches were only to have it compile without throwing warning/errors... ? (don't think it "works")
The FreeBSD ports I've seen do a: #define APP_PREFIX "/usr/local", and don't use binary relocation (I believe Linux has the same default, but haven't tried using binreloc on Linux yet) We used to do the same in the Mac OS X wrapper, before I ported app/configmanager (i.e. set a prefix explicitly, by using the --prefix option to codeblocks).
Using the BinReloc "library" or Thomas's readlink("/proc/self/exe") should amount to the same thing in the end, but will only work reliably on Linux. All I was asking was that app.cpp and configmanager.cpp should use the same code to determine prefix/datadir ? But I can test the --enable-binreloc version on Linux, and see if it relocates OK.
thomas:
--- Quote from: mandrav on November 22, 2006, 09:37:51 am ---We do have *BSD users and it does work for them. Heck, we had even got a patch for binreloc to work on *BSD.
--- End quote ---
It's nice that it works for them :) For your reference, the code that we use looks like this:
base = wxString(SELFPATH,wxConvUTF8);
if (base.IsEmpty())
base = _T(".");
#define SELFPATH (br_thread_local_store (br_locate ((void *) "")))
char *br_locate (void *symbol)
{
char line[5000];
FILE *f;
char *path;
br_return_val_if_fail (symbol != NULL, (char*)NULL);
f = fopen ("/proc/self/maps", "r");
if (!f)
return (char*)NULL;
while (!feof (f))
... <more code>
#define br_return_val_if_fail(expr,val) if (!(expr)) {fprintf (stderr, "..."); return val;}
I'm so happy it works nicely for BSD. :)
--- Quote ---Hardcoding is out of the question.
--- End quote ---
That's unfortunate, because that's what we do now.
--- Quote ---Why, all of the sudden, do you want to change things regarding this matter?
--- End quote ---
I don't want to change things regarding this matter at all. Heck, I could imagine more pleasant things to do.
As you asked for, I was making user plugin paths depending on the location of the config file found. The ConfigManager instances know nothing about the underlying file, that's handled by the related factory class.
Thus, the executable's path (and other paths) must be known a lot earlier now, this can no longer wait until the application eventually figures it out and sets it. Therefore, I implemented something which I thought should work.
In the end, as binreloc depends on /proc/self too, my 6 lines of code do not change any single thing, except they are 6 lines instead of 550 lines...
afb:
AFAIK: FreeBSD ports will find stuff relative to the $PREFIX it is compiled for (default /usr/local but could be /opt). I don't think we need any binary relocation other than that, i.e. like AutoPackage's BinReloc does it - so that you can move the binaries ? But I only know what I read in the FreeBSD Porter's Handbook, I'm not really a BSD user.
I will be happy to test on PC-BSD 1.2 (based on FreeBSD 6.1). But /proc is empty, so that does not work.
mandrav:
--- Quote --- For your reference, the code that we use looks like this:
--- End quote ---
--- Quote from: mandrav ---Admittedly, I have not looked into binreloc's code
--- End quote ---
Thanks for posting the code here or else I couldn't read it, should I wanted to...
--- Quote from: thomas ---I'm so happy it works nicely for BSD. :)
--- End quote ---
And thanks for the sarcasm too.
--- Quote ---
--- Quote ---Hardcoding is out of the question.
--- End quote ---
That's unfortunate, because that's what we do now.
--- End quote ---
So we are hardcoding /usr/local, /opt or whatever? Strange, I haven't noticed... What revision did this happen in and who did it?
--- Quote ---
--- Quote ---Why, all of the sudden, do you want to change things regarding this matter?
--- End quote ---
I don't want to change things regarding this matter at all.
--- End quote ---
All I know is that there was no need to discuss this issue (i.e. it was a non-issue, we had no complaints so far) up to now and suddenly I see a two pages long topic on the subject. I just want to know what triggered this.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version