NSBundle loads resources from the wrong version #351
Comments
|
On windows, I se this error, which is new.
|
|
On 21 Nov 2023, at 12:07, Riccardo ***@***.***> wrote:
On windows, I se this error, which is new.
It appears that this issue has many aspects.
2023-11-21 12:46:36.327 DataBasin[15152:9020] Warning: [NSBundle+bundleForLibrary:version:] called without version and unable to infer version from library name (C:\msys64\mingw64\Local\Applications\DataBasin.app\DataBasin.exe).
Yes, it's new because I just added it :-)
Hopefully it should help figure out problems ... in this case the path is clearly an app rather than a library, so if you run under gdb and set a breakpoint when the warning is logged you can look at the stack and see what's calling the method with bad parameters and why.
|
|
That particular error seems to be windows-specific. The code was comparing two paths (location of class definition and the executable) to see if they were the same (ie the class was defined in the executable rather than a library). The comparison said the two were different, but that was because the path separators were slashes in one and backslashes in the other. |
|
FYI [NSBundle+bundleForLibrary:version:] tries to infer the version from the library name/path if it is not provided as an argument. So if it's loading the wrong version that's because |
|
From looking at the code in loadNibNamed:... it doesn't appear as though any of those methods call bundleForLibrary:version: or anything that might do a library specific search. They assume that bundleForClass: will return the right path. I'm not in front of my computer at the moment so I could be mistaken, but I don't think it does. This might be part of our issue. |
|
|
I just checked and the code seems to solve my issue, bundle resource now loads. |
|
I get dozens of messages when running GWorkspace: 2023-11-27 17:26:06.983 GWorkspace[32433:32433] Warning: [NSBundle+bundleForLibrary:version:] called without version and unable to infer version from library name (/home/multix/gnustep-cvs/apps-gworkspace/GWorkspace). |
|
yes sorry, a second clean&rebuild of base fixed that... strange |
|
Things improved, but I still have warnings when e.g. GWorkspace is started but the CWD is its build dir (e.g. app-gworkspace) but all is fine if the CWD is e.g. just the home directory.
|
|
I think you need to look into where/how the wrong path is being found. So presumably one of those functions return the wrong result in some cases |
|
@rfm I added two logs at line 1163. I get when launching from the GIT repo dir: The running process is correct, the private symbol path is wrong If I launch GWorkspace from my home, I get: so the latter is then relative? Do you expect GSPrivateSymbolPath to be an absolute path? |
|
On 19 Dec 2023, at 12:30, Riccardo ***@***.***> wrote:
@rfm I added two logs at line 1163. I get when launching from the GIT repo dir:
2023-12-19 12:01:49.027 GWorkspace[5783:5783] exec path: /System/Applications/GWorkspace.app/GWorkspace
2023-12-19 12:01:49.028 GWorkspace[5783:5783] private symbol path. /home/multix/gnustep-cvs/apps-gworkspace/GWorkspace
2023-12-19 12:01:49.028 GWorkspace[5783:5783] Warning: [NSBundle+bundleForClass:] unable to determine version of library '/home/multix/gnustep-cvs/apps-gworkspace/GWorkspace' containing 'StartAppWin' for executable '/System/Applications/GWorkspace.app/GWorkspace'
The running process is correct, the private symbol path is wrong
If I launch GWorkspace from my home, I get:
2023-12-19 12:30:31.519 GWorkspace[752:752] exec path: /System/Applications/GWorkspace.app/GWorkspace
2023-12-19 12:30:31.519 GWorkspace[752:752] private symbol path. GWorkspace
so the latter is then relative? Do you expect GSPrivateSymbolPath to be an absolute path?
Yes, we do.
However, i came across a comment in GSPrivate.h saying that the dyanamic linker dladdr() function on some systems returns argv[0] (rather than a full path) then the symbol is located in the executable rather than a library.
So I just comitted a change intended to detect that situation and return the full path of the executable instead of argv[0]. Hopefully that will fix the issue.
|
|
Ok, now the warning seems to be gone, I see now: or which looks the same, independently if I started in my home our source dir and the warning is gone. Seems fixed! I think this needs to be tested a bit! |
|
Do you think it's OK to close this issue now? |
|
I think we are OK on this one now. |
|
Yes, I confirm... all originally discovered issues were solved. |
When asked to load resources from gui (class NSApplication) if e.g. gui version is 1.30 and there are several versions in the resources dir, the wrong one gets loaded.
E.g. with current 0.30 the resources are looked on 0.28 if present.
The text was updated successfully, but these errors were encountered: