Re: Loading bundle resources using GNUstep runtime 2.0, was: Hint towards solution? Re: ProjectCenter running or building
Hi, Another part of the mystery that we shouldn't forget is that _frameworkVersion is not being set, it is always null. So even if the standard locations were being checked, NSBundle would not not know what version subdirectory to look in... I am not sure what sets the framework version, and why it is being lost... Previously, Riccardo was not able to replicate this issue that we have been having. Patryk On January 6, 2020 at 1:50 AM, Riccaro Mottola wrote: Hi Patryk, On 2020-01-02 19:24:08 +0100 Patryk Laurent wrote: Happy new year to you as well! I do see thoss errors when I just openapp GWorkspace on its own. Furthermore there is an error specifically about failing to load InspectorWin [1]. With the NSLog() at line 2280 I see it (among many other things) has _frameworkVersion null [2]. Thank you. I don't see a specific GWorkspace issue, but you seem indeed to have a generic framework issue and once things do not load, various errors appear. I have now clang+libobjc2 set up and I cannot reproduce this issue. Let's try to work together with Fred and David and see if this can sorted out for you. Riccardo -- On February 1, 2020 at 3:22 PM, Johannes Brakensiek wrote: Hi Patryk, On 1 Feb 2020, at 19:18, Patryk Laurent wrote: Ok, armed with this knowledge, I was able to get ProjectCenter to "work" by doing 2 things: thank you for proving we’re on the right track. ;) What does this all mean, and why does this help things work? I don't know, but I would like to know, as well as the "right" way to fix it. Well, I think it works, because you have moved the framework to the main bundle (the app bundle). The main bundle path is known and loading from the main bundle works. Why does it not work otherwise? Here I can just guess. There is much magic going on within NSBundle it seems. This comment beginning in line 638 seems as it is giving some hints: /* Nicola & Mirko: Frameworks can be used in an application in two different ways: […] (2) the framework was linked into the application. This is much more difficult, because without using tricks, we have no way of knowing where the framework bundle (needed eg for resources) is on disk, and we have no way of knowing what the class list is, or the version. So the trick we use in this case to work around those problems is that gnustep-make generates a 'NSFramework_xxx' class and compiles it into each framework. By asking to the class, we can get the version information and the list of classes which were compiled into the framework. To get the location of the framework on disk, we try using advanced dynamic linker features to get the shared object file on disk from which the NSFramework_xxx class was loaded. If that doesn't work, because the dynamic linker can't provide this information on this platform (or maybe because the framework was statically linked into the application), we have a fallback trick :-) We look for the framework in the standard locations and in the main bundle. This might fail if the framework is not in a standard location or there is more than one installed framework of the same name (and different versions?). Using the debugger I did not see that „the standard locations“ (like …/Library/Frameworks) were tested. So currently it seems to me the fallback case is never reached. It might well be that the default way of looking up the bundle path using GSPrivateSymbolPath() returns something that seems valid but does not work or just is the path of the main bundle. We’d need to further investigate here. So there might be two issues: I suspect using the GNUstep runtime version 2.0 there are problems using these „advanced dynamic linker features“. This way of looking up the bundle path relies on using GSPrivateSymbolPath(). Already the code comments of NSBundle make clear that this is a very fragile solution („But in real life GSPrivateSymbolPath() is risky“). So I don’t know if there is a proper way to fix this for the newest runtime. Any help from experienced people is appreciated here. If this fails in the way that it returns a valid but wrong value I won’t be able to fix it. If the fallback way of looking up the bundle path fails, this is something I might be able to at least debug to some extend. The responsible code seems to begin at line 838, the most important function called here seems to be _find_framework() beginning in line 547. The constant which should be set correctly is GSFrameworksDirectory. First hint: If this fails NSWarnMLog (to be activated by which debug flag?) should output an error message (see line 869). So this is the current result of my research late in the night. ;) Regards Johannes
Re: Loading bundle resources using GNUstep runtime 2.0, was: Hint towards solution? Re: ProjectCenter running or building
Hi Johannes, > On Feb 1, 2020, at 3:22 PM, Johannes Brakensiek > wrote: > > Why does it not work otherwise? Here I can just guess. There is much magic > going on within NSBundle it seems. This comment beginning in line 638 seems > as it is giving some hints: > Yes the logic in NSBundle.m seems quite complex. Makes me wonder if introducing a "GNUSTEP_FRAMEWORK_PATH" could help, like Java's "CLASSPATH"...? > Using the debugger I did not see that „the standard locations“ (like > …/Library/Frameworks) were tested. So currently it seems to me the fallback > case is never reached. It might well be that the default way of looking up > the bundle path using GSPrivateSymbolPath() returns something that seems > valid but does not work or just is the path of the main bundle. We’d need to > further investigate here. > Yes... it is surprising that the "standard" location isn't searched... the files are clearly there. > So this is the current result of my research late in the night. ;) > Hopefully that code wasn't too scary to be looking at before sleep ;) Regards, Patryk
Re: Loading bundle resources using GNUstep runtime 2.0, was: Hint towards solution? Re: ProjectCenter running or building
Hi Patryk, On 1 Feb 2020, at 19:18, Patryk Laurent wrote: Ok, armed with this knowledge, I was able to get ProjectCenter to "work" by doing 2 things: thank you for proving we’re on the right track. ;) What does this all mean, and why does this help things work? I don't know, but I would like to know, as well as the "right" way to fix it. Well, I think it works, because you have moved the framework to the main bundle (the app bundle). The main bundle path is known and loading from the main bundle works. Why does it not work otherwise? Here I can just guess. There is much magic going on within NSBundle it seems. This comment beginning in line 638 seems as it is giving some hints: ``` /* Nicola & Mirko: Frameworks can be used in an application in two different ways: […] (2) the framework was linked into the application. This is much more difficult, because without using tricks, we have no way of knowing where the framework bundle (needed eg for resources) is on disk, and we have no way of knowing what the class list is, or the version. So the trick we use in this case to work around those problems is that gnustep-make generates a 'NSFramework_xxx' class and compiles it into each framework. By asking to the class, we can get the version information and the list of classes which were compiled into the framework. To get the location of the framework on disk, we try using advanced dynamic linker features to get the shared object file on disk from which the NSFramework_xxx class was loaded. If that doesn't work, because the dynamic linker can't provide this information on this platform (or maybe because the framework was statically linked into the application), we have a fallback trick :-) We look for the framework in the standard locations and in the main bundle. This might fail if the framework is not in a standard location or there is more than one installed framework of the same name (and different versions?). ``` Using the debugger I did not see that „the standard locations“ (like …/Library/Frameworks) were tested. So currently it seems to me the fallback case is never reached. It might well be that the default way of looking up the bundle path using GSPrivateSymbolPath() returns something that seems valid but does not work or just is the path of the main bundle. We’d need to further investigate here. So there might be two issues: 1. I suspect using the GNUstep runtime version 2.0 there are problems using these „advanced dynamic linker features“. This way of looking up the bundle path relies on using ```GSPrivateSymbolPath()```. Already the code comments of NSBundle make clear that this is a very fragile solution („But in real life GSPrivateSymbolPath() is risky“). So I don’t know if there is a proper way to fix this for the newest runtime. Any help from experienced people is appreciated here. If this fails in the way that it returns a valid but wrong value I won’t be able to fix it. 2. If the fallback way of looking up the bundle path fails, this is something I might be able to at least debug to some extend. The responsible code seems to begin at line 838, the most important function called here seems to be ```_find_framework()``` beginning in line 547. The constant which should be set correctly is ```GSFrameworksDirectory```. First hint: If this fails ```NSWarnMLog``` (to be activated by which debug flag?) should output an error message (see line 869). So this is the current result of my research late in the night. ;) Regards Johannes
Hint towards solution? Re: ProjectCenter running or building
Hi Johannes, Possibly some good news below... On January 30, 2020 at 11:29 PM, Johannes Brakensiek wrote: Hi Patryk, On 31 Jan 2020, at 6:44, Patryk Laurent wrote: I’ve not yet come to the point to figure out why the bundle path might be set incorrect. ... I’ve currently got problems debugging + (NSBundle *) bundleForClass: (Class)aClass using gdb because this method gets called too often. I’ll try to insert logging of some debugging output and recompile maybe. Thanks for helping here - maybe anyone has a good idea regarding the cause of the issue? Johannes Ok, armed with this knowledge, I was able to get ProjectCenter to "work" by doing 2 things: (1) In ProjectCenter's build directory, before make install, copy Framework into ./ProjectCenter.app/ cd apps-projectcenter make cp Framework ./ProjectCenter.app/ make install (2) Then in libs-base, alter Source/NSBundle.m by adding the following two lines (lines 2103 and 2104): 2100 primary = [rootPath stringByAppendingPathComponent: @"Resources"]; 2101 contents = bundle_directory_readable(primary); 2102 addBundlePath(array, contents, primary, subPath, nil); 2103 addBundlePath(array, contents, [rootPath stringByAppendingPathComponent: @"Framework"], subPath, nil); 2104 addBundlePath(array, contents, [[rootPath stringByAppendingPathComponent: @"Framework"] stringByAppendingPathComponent: @"English.lproj"], subPath, nil); Then make and make install libs-base. Now openapp ProjectCenter.app, and the app is able to load the LogPanel and present it as necessary, etc. What does this all mean, and why does this help things work? I don't know, but I would like to know, as well as the "right" way to fix it. Best, Patryk
Re: ProjectCenter running or building
Hi Patryk, On 31 Jan 2020, at 6:44, Patryk Laurent wrote: Manually looking for LogPanel.nib, I don’t see it anywhere on my system. I do see LogPanel.gorm, however. Could the problem just be that the .nib file isn’t being created anymore for some reason? What code/makefile creates the .nib? gorm files are preferred by GNUstep given the same name as the corresponding nib file. This is ok. I tried to track this down a little for GWorkspace. The InspectorWin nibs/gorm files are located within the Inspector.framework. The framework is loaded, but when it comes to loading the nib files, the name/path of the bundle is set to the values of the main bundle not those of the framework. Due to the wrong path nib loading failes. I’ve not yet come to the point to figure out why the bundle path might be set incorrect. This is the point where I’m currently stuck: ``` Breakpoint 1, +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] ( self=0x779b4700 <._OBJC_CLASS_NSBundle>, _cmd=0x77f4be10 <.objc_selector_loadNibNamed:owner:_C320:81624>, aNibName=0x77f4d740 <.objc_str_InspectorWin>, owner=0x3f18cf8) at NSBundleAdditions.m:65 65if (owner == nil || aNibName == nil) (gdb) po owner (gdb) po aNibName InspectorWin (gdb) s 69 table = [NSDictionary dictionaryWithObject: owner forKey: NSNibOwner]; (gdb) s 83bundle = [self bundleForClass: [owner class]]; (gdb) s 84if (bundle != nil && [bundle loadNibFile: aNibName (gdb) s 86withZone: [owner zone]] == YES) (gdb) po bundle ``` That last value is wrong, afaik. I’ve currently got problems debugging + (NSBundle *) bundleForClass: (Class)aClass using gdb because this method gets called too often. I’ll try to insert logging of some debugging output and recompile maybe. Thanks for helping here - maybe anyone has a good idea regarding the cause of the issue? Johannes
Re: ProjectCenter running or building
Manually looking for LogPanel.nib, I don’t see it anywhere on my system. I do see LogPanel.gorm, however. Could the problem just be that the .nib file isn’t being created anymore for some reason? What code/makefile creates the .nib? Patryk On Dec 30, 2019, at 00:23, Fred Kiefer wrote: > > In your examples the name was „ProjectCenter“ not „LogPanel“. You need to > continue your debugging until you get to that name. Only this resource seems > to get loaded from a framework. For the other resources having a framework > version of nil is correct. > > Fred > >> Am 30.12.2019 um 01:17 schrieb Patryk Laurent : >> >>> On December 29, 2019 at 12:31 PM, Fred Kiefer wrote: >>> >>> Thank you for your tests. I had a look into the NSBundle code in base and >>> from that I think that we have an issue with frameworks here. Is clang >>> supporting frameworks? >>> The code in base doesn’t have any log statements that we could use. So this >>> means you will have to switch to a debugger and run ProjectCenter with a >>> breakpoint on NSBundle.m:2280 and wait until we get around with the name >>> „LogPanel“ and see whether the framework version gets added correctly. >>> >> >> From within the debugger I am seeing that _frameworkVersion tends to be nil. >> And I'm having trouble seeing the values of NSStrings... so maybe there's >> something up. >> >> Patryk >> >> >> (base) >> patryk@wax:~/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app$ >> lldb ./ProjectCenter >> (lldb) target create "./ProjectCenter" >> Current executable set to './ProjectCenter' (x86_64). >> >> (lldb) breakpoint set --file NSBundle.m --line 2280 >> Breakpoint 1: no locations (pending). >> WARNING: Unable to resolve breakpoint to any actual locations. >> >> (lldb) run >> Process 3951 launched: >> '/home/patryk/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app/ProjectCenter' >> (x86_64) >> 1 location added to breakpoint 1 >> Process 3951 stopped >> * thread #1, name = 'ProjectCenter', stop reason = breakpoint 1.1 >>frame #0: 0x77731997 libgnustep-base.so.1.27`-[NSBundle >> pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", >> name=0x77a8c978, extension=0xe1b34f3e802c, >> subPath=0x) at NSBundle.m:2283:7 >> 2280 NSString *rootPath; >> 2281 >> 2282 #if !defined(_WIN32) >> -> 2283 if (_frameworkVersion) >> 2284 rootPath = [NSString stringWithFormat: @"%@/Versions/%@", [self >> bundlePath], >> 2285 _frameworkVersion]; >> 2286 else >> >> (lldb) fr va _frameworkVersion >> (NSString *) _frameworkVersion = nil >> (lldb) n >> Process 3951 stopped >> * thread #1, name = 'ProjectCenter', stop reason = step over >>frame #0: 0x777319e5 libgnustep-base.so.1.27`-[NSBundle >> pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", >> name=0x77a8c978, extension=0xe1b34f3e802c, >> subPath=0x) at NSBundle.m:2288:16 >> 2285 _frameworkVersion]; >> 2286 else >> 2287 #endif >> -> 2288 rootPath = [self bundlePath]; >> 2289 >> 2290 return [NSBundle _pathForResource: name >> 2291 ofType: extension >> >> (lldb) n >> Process 3951 stopped >> * thread #1, name = 'ProjectCenter', stop reason = step over >>frame #0: 0x777319f4 libgnustep-base.so.1.27`-[NSBundle >> pathForResource:ofType:inDirectory:](self=0x00683768, >> _cmd=, name=0x77a8c978, extension=0xe1b34f3e802c, >> subPath=0x) at NSBundle.m:2290:10 >> 2287 #endif >> 2288 rootPath = [self bundlePath]; >> 2289 >> -> 2290 return [NSBundle _pathForResource: name >> 2291 ofType: extension >> 2292 inRootPath: rootPath >> 2293 inDirectory: subPath]; >> >> (lldb) fr va rootPath >> (NSString *) rootPath = 0x006838a8 >> (lldb) >
Re: rdynamic? Re: ProjectCenter running or building
Hi Patryk, hi everyone, I don't know if this is of any use for anyone, but let's try: Am 18.01.20 um 02:08 schrieb Patryk Laurent: On Jan 13, 2020, at 01:24, David Chisnall wrote: -rdynamic is fine. This means put all symbols on the dynamic symbol table. The problem is -r, which means do a partial link. Some linkers do too much of one and prevent the final link from correctly placing everything in the correct sections. In the below compile likes there is no -r while ProjectCenter is being built... so can anyone think of any other reason for the ProjectCenter failures and how to fix them? I set a breakpoint at [NSBundle loadNibNamed:owner:]. This is what I get when when I start ProjectCenter when it comes to the LogPanel gorm file: Breakpoint 1, +[NSBundle(NSBundleAdditions) loadNibNamed:owner:] ( self=0x77a02700 <._OBJC_CLASS_NSBundle>, _cmd=0x77fc2ee8 <.objc_selector_loadNibNamed:owner:_C320:81624>, aNibName=0x99bf3d0c3bb2ec44, owner=0xd21068) at NSBundleAdditions.m:65 65if (owner == nil || aNibName == nil) (gdb) po owner (gdb) s 69table = [NSDictionary dictionaryWithObject: owner forKey: NSNibOwner]; (gdb) s 83bundle = [self bundleForClass: [owner class]]; (gdb) s 84if (bundle != nil && [bundle loadNibFile: aNibName (gdb) po aNibName Cannot access memory at address 0x99bf3d0c3bb2ec44 (gdb) s 86withZone: [owner zone]] == YES) (gdb) s 84if (bundle != nil && [bundle loadNibFile: aNibName (gdb) s 86withZone: [owner zone]] == YES) (gdb) s 84if (bundle != nil && [bundle loadNibFile: aNibName (gdb) s 92bundle = [self mainBundle]; (gdb) s 96 withZone: [owner zone]]; (gdb) s 94return [bundle loadNibFile: aNibName (gdb) s 0x774e3c0c in objc_msgSend_fpret () from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6 (gdb) bt #0 0x774e3c0c in objc_msgSend_fpret () from /usr/GNUstep/Local/Library/Libraries/libobjc.so.4.6 #1 0x77fa5f9b in -[PCLogController init] (self=0xd21068, _cmd=) at PCLogController.m:105 #2 0x77fa5f24 in +[PCLogController sharedLogController] ( self=, _cmd=) at PCLogController.m:86 #3 0x77fa5bdc in PCLog (sender=0xf4a0b8, tag=0, format=0x77fc5a58, args=) at PCLogController.m:28 #4 PCLogInfo (sender=0xf4a0b8, format=0x77fc5a58) at PCLogController.m:40 #5 0x77f8802f in -[PCBundleManager loadBundleWithFullPath:] ( self=0xf4a0b8, _cmd=, path=0x98eab8) at PCBundleManager.m:403 #6 0x77f87cca in -[PCBundleManager bundleOfType:withClassName:] ( self=0xf4a0b8, _cmd=, type=0x40c910 , className=) at PCBundleManager.m:324 #7 0x77f87a82 in -[PCBundleManager objectForClassName:bundleType:protocol:] (self=0x441a78, _cmd=out>, className=0xd14e48, bundleExtension=, proto=0x40cab0 <._OBJC_PROTOCOL_PCPrefsSection>) at PCBundleManager.m:244 #8 0x0040505a in -[PCPrefController loadPrefsSections] ( self=0xf42888, _cmd=) at PCPrefController.m:313 #9 0x00404711 in -[PCPrefController init] (self=0xf42888, --Type for more, q to quit, c to continue without paging-- _cmd=) at PCPrefController.m:57 #10 0x004046b4 in +[PCPrefController sharedPCPreferences] ( self=, _cmd=) at PCPrefController.m:43 #11 0x00402138 in -[PCAppController init] (self=0xde48d8, _cmd=) at PCAppController.m:52 #12 0x77da3782 in -[GSNibItem initWithCoder:] (self=0xdb7da8, _cmd=, aCoder=0x8067b8) at GSGormLoading.m:551 #13 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x8067b8, _cmd=0x77a76158 <.objc_selector_decodeValueOfObjCType:at:_>, type=, address=0x7fffcb30) at NSUnarchiver.m:929 #14 0x776c9690 in -[GSSet initWithCoder:] (self=0xf4aee8, _cmd=, aCoder=0x8067b8) at GSSet.m:249 #15 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x8067b8, _cmd=0x77f20550 <.objc_selector_decodeValueOfObjCType:at:_v320:8r*16^v24>, type=, address=0xb17e50) at NSUnarchiver.m:929 #16 0x77da2d69 in -[GSNibContainer initWithCoder:] (self=0xb17e28, _cmd=, aCoder=0x8067b8) at GSGormLoading.m:384 #17 0x777f9d00 in -[NSUnarchiver decodeValueOfObjCType:at:] ( self=0x8067b8, _cmd=0x77a75ba8 <.objc_selector_decodeValueOfObjCType:at:_v320:8r*16^v24>, type=, address=0x7fffcce0) at NSUnarchiver.m:929 --Type for more, q to quit, c to continue without paging-- #18 0x77717edf in -[NSCoder decodeObject] (self=0x441a78, _cmd=) at NSCoder.m:249 #19 0x77dc926f in -[GSGormLoader loadModelData:externalNameTable:withZone:] (self=, _cmd=, data=0xea5718, context=0x7545b8, zone=0x77a4c080 ) at GSGormLoader.m:114 #20 0x77c786dd in +[NSBundle(NSBundleAdditions) loadNibFile:externalNameTable:withZone:] (self=, _cmd=,
Re: rdynamic? Re: ProjectCenter running or building
Hi, > On Jan 13, 2020, at 01:24, David Chisnall wrote: > > -rdynamic is fine. This means put all symbols on the dynamic symbol table. > The problem is -r, which means do a partial link. Some linkers do too much > of one and prevent the final link from correctly placing everything in the > correct sections. In the below compile likes there is no -r while ProjectCenter is being built... so can anyone think of any other reason for the ProjectCenter failures and how to fix them? Patryk >> On 13 Jan 2020, at 00:05, Patryk Laurent wrote: >> >> Hi, >> >>> On December 29, 2019 at 6:21 AM, David Chisnall >>> wrote: >>> >>> On 29 Dec 2019, at 13:16, Fred Kiefer wrote: > 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass > PCProjectDocument not found >>> >>> Is this project using ld -r (I forget what GNUstep Make calls this - >>> subprojects?)? If so, it may be the same issue as Base Additions, which >>> can’t be linked with BFD LD. >>> >>> David >> >>> On January 6, 2020 at 3:48 AM, David Chisnall >>> wrote: >>> >>> On 05/01/2020 16:15, Patryk Laurent wrote: Do you think the bug is also is in ld.gold? During build, we set LD=/usr/bin/ld.gold (for example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46) >>> >>> Is $LD actually used to build? Most of the time, $CC is invoked as the >>> linker, so you need -fuse-ld=gold in the LDFLAGS. >>> >>> David >> >> While building ProjectCenter I see the use of clang -rdynamic, it looks like >> it's coming in from gnustep-config --objc-libs. Is this the "-r" you were >> mentioning before, and may be causing the problem with the >> frameworks/subprojects and resource bundle loading? >> >> Should we try to find some way to disable it? What is the recommended way >> to do this? >> >> Best, >> Patryk >> >> >> clang -shared -Wl,-soname,libProjectCenter.so.0 -rdynamic >> -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread -fexceptions -o >> ./ProjectCenter.framework/Versions/0.6.2/./libProjectCenter.so.0.6.2 obj/ >> ProjectCenter.obj/NSFramework_ProjectCenter.o >> obj/ProjectCenter.obj/PCBundleManager.m.o >> obj/ProjectCenter.obj/PCEditorManager.m.o >> obj/ProjectCenter.obj/PCMakefileFactory.m.o >> obj/ProjectCenter.obj/PCFileManager.m.o obj/ >> ProjectCenter.obj/PCAddFilesPanel.m.o >> obj/ProjectCenter.obj/PCFileCreator.m.o obj/ProjectCenter.obj/ >> PCSaveModified.m.o obj/ProjectCenter.obj/PCProjectManager.m.o >> obj/ProjectCenter.obj/PCProject.m.o obj/ >> ProjectCenter.obj/PCProjectWindow.m.o >> obj/ProjectCenter.obj/PCProjectInspector.m.o obj/ProjectCenter.obj/ >> PCProjectBuilder.m.o obj/ProjectCenter.obj/PCProjectBuilderOptions.m.o >> obj/ProjectCenter.obj/ PCProjectBuilderPanel.m.o >> obj/ProjectCenter.obj/PCProjectLauncher.m.o obj/ProjectCenter.obj/ >>PCProjectLauncherPanel.m.o obj/ProjectCenter.obj/PCProjectEditor.m.o >> obj/ProjectCenter.obj/PCProjectBrowser.m.o >> obj/ProjectCenter.obj/PCProjectLoadedFiles.m.o >> obj/ProjectCenter.obj/PCProjectLoadedFilesPanel.m.o obj/ >> ProjectCenter.obj/PCButton.m.o obj/ProjectCenter.obj/PCFileNameField.m.o >> obj/ProjectCenter.obj/PCFileNameIcon.m.o >> obj/ProjectCenter.obj/PCLogController.m.o >> obj/ProjectCenter.obj/PCAuxiliaryWindow.m.o -L../ >> ProjectCenter/./obj-L/home/patryk/GNUstep/Library/Libraries >> -L/usr/GNUstep/Local/Library/Libraries >> -L/usr/GNUstep/System/Library/Libraries -lobjc -lgnustep-base -lgnustep-gui >> >> >> clang -shared -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread >> -fexceptions -o ./ProjectCe >> nter.debugger/./ProjectCenter ./obj/ProjectCenter.obj/PCDebugger.m.o >> ./obj/ProjectCenter.obj/PCDebuggerView.m. >> o ./obj/ProjectCenter.obj/PipeDelegate.m.o >> -L../../../Framework/ProjectCenter.framework/. -L/home/patryk/ >> GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries >> -L/usr/GNUstep/System/Library/Libraries >> -lgnustep-gui -lgnustep-base -lpthread -lobjc -lm >> >> >> clang -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread >> -fexceptions -fobjc-runtime=gnuste >> p-2.0 -fblocks -o ProjectCenter.app/./ProjectCenter \ >> ./obj/ProjectCenter.obj/PCAppController.m.o >> ./obj/ProjectCenter.obj/PCInfoController.m.o >> ./obj/ProjectCenter.obj/PCMenuController.m.o >> ./obj/ProjectCenter.obj/PCPrefController.m.o >> ./obj/ProjectCenter.obj/ProjectCenter_main.m.o >> -L./Framework/ProjectCenter.framework/. >> -L/home/patryk/GNUstep/Library/Libraries >> -L/usr/GNUstep/Local/Library/Libraries >> -L/usr/GNUstep/System/Library/Libraries -lProjectCenter -lgnustep-gui >> -lgnustep-base -lpthread -lobjc -lm >> >> >> >> >
Re: rdynamic? Re: ProjectCenter running or building
-rdynamic is fine. This means put all symbols on the dynamic symbol table. The problem is -r, which means do a partial link. Some linkers do too much of one and prevent the final link from correctly placing everything in the correct sections. David > On 13 Jan 2020, at 00:05, Patryk Laurent wrote: > > Hi, > > On December 29, 2019 at 6:21 AM, David Chisnall > wrote: > >> On 29 Dec 2019, at 13:16, Fred Kiefer wrote: >>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass PCProjectDocument not found >> >> Is this project using ld -r (I forget what GNUstep Make calls this - >> subprojects?)? If so, it may be the same issue as Base Additions, which >> can’t be linked with BFD LD. >> >> David > > On January 6, 2020 at 3:48 AM, David Chisnall > wrote: > >> On 05/01/2020 16:15, Patryk Laurent wrote: >>> Do you think the bug is also is in ld.gold? During build, we set >>> LD=/usr/bin/ld.gold (for >>> example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46) >> >> Is $LD actually used to build? Most of the time, $CC is invoked as the >> linker, so you need -fuse-ld=gold in the LDFLAGS. >> >> David > > While building ProjectCenter I see the use of clang -rdynamic, it looks like > it's coming in from gnustep-config --objc-libs. Is this the "-r" you were > mentioning before, and may be causing the problem with the > frameworks/subprojects and resource bundle loading? > > Should we try to find some way to disable it? What is the recommended way to > do this? > > Best, > Patryk > > > clang -shared -Wl,-soname,libProjectCenter.so.0 -rdynamic > -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread -fexceptions -o > ./ProjectCenter.framework/Versions/0.6.2/./libProjectCenter.so.0.6.2 obj/ >ProjectCenter.obj/NSFramework_ProjectCenter.o > obj/ProjectCenter.obj/PCBundleManager.m.o > obj/ProjectCenter.obj/PCEditorManager.m.o > obj/ProjectCenter.obj/PCMakefileFactory.m.o > obj/ProjectCenter.obj/PCFileManager.m.o obj/ > ProjectCenter.obj/PCAddFilesPanel.m.o obj/ProjectCenter.obj/PCFileCreator.m.o > obj/ProjectCenter.obj/ PCSaveModified.m.o > obj/ProjectCenter.obj/PCProjectManager.m.o > obj/ProjectCenter.obj/PCProject.m.o obj/ > ProjectCenter.obj/PCProjectWindow.m.o > obj/ProjectCenter.obj/PCProjectInspector.m.o obj/ProjectCenter.obj/ > PCProjectBuilder.m.o obj/ProjectCenter.obj/PCProjectBuilderOptions.m.o > obj/ProjectCenter.obj/ PCProjectBuilderPanel.m.o > obj/ProjectCenter.obj/PCProjectLauncher.m.o obj/ProjectCenter.obj/ > PCProjectLauncherPanel.m.o obj/ProjectCenter.obj/PCProjectEditor.m.o > obj/ProjectCenter.obj/PCProjectBrowser.m.o > obj/ProjectCenter.obj/PCProjectLoadedFiles.m.o > obj/ProjectCenter.obj/PCProjectLoadedFilesPanel.m.o obj/ > ProjectCenter.obj/PCButton.m.o obj/ProjectCenter.obj/PCFileNameField.m.o > obj/ProjectCenter.obj/PCFileNameIcon.m.o > obj/ProjectCenter.obj/PCLogController.m.o > obj/ProjectCenter.obj/PCAuxiliaryWindow.m.o -L../ > ProjectCenter/./obj-L/home/patryk/GNUstep/Library/Libraries > -L/usr/GNUstep/Local/Library/Libraries > -L/usr/GNUstep/System/Library/Libraries -lobjc -lgnustep-base -lgnustep-gui > > > clang -shared -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread > -fexceptions -o ./ProjectCe > nter.debugger/./ProjectCenter ./obj/ProjectCenter.obj/PCDebugger.m.o > ./obj/ProjectCenter.obj/PCDebuggerView.m. > o ./obj/ProjectCenter.obj/PipeDelegate.m.o > -L../../../Framework/ProjectCenter.framework/. -L/home/patryk/ > GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries > -L/usr/GNUstep/System/Library/Libraries > -lgnustep-gui -lgnustep-base -lpthread -lobjc -lm > > > clang -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread > -fexceptions -fobjc-runtime=gnuste > p-2.0 -fblocks -o ProjectCenter.app/./ProjectCenter \ > ./obj/ProjectCenter.obj/PCAppController.m.o > ./obj/ProjectCenter.obj/PCInfoController.m.o > ./obj/ProjectCenter.obj/PCMenuController.m.o > ./obj/ProjectCenter.obj/PCPrefController.m.o > ./obj/ProjectCenter.obj/ProjectCenter_main.m.o > -L./Framework/ProjectCenter.framework/. > -L/home/patryk/GNUstep/Library/Libraries > -L/usr/GNUstep/Local/Library/Libraries > -L/usr/GNUstep/System/Library/Libraries -lProjectCenter -lgnustep-gui > -lgnustep-base -lpthread -lobjc -lm > > > >
rdynamic? Re: ProjectCenter running or building
Hi, On December 29, 2019 at 6:21 AM, David Chisnall wrote: On 29 Dec 2019, at 13:16, Fred Kiefer wrote: 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass PCProjectDocument not found Is this project using ld -r (I forget what GNUstep Make calls this - subprojects?)? If so, it may be the same issue as Base Additions, which can’t be linked with BFD LD. David On January 6, 2020 at 3:48 AM, David Chisnall wrote: On 05/01/2020 16:15, Patryk Laurent wrote: Do you think the bug is also is in ld.gold? During build, we set LD=/usr/bin/ld.gold (for example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46) Is $LD actually used to build? Most of the time, $CC is invoked as the linker, so you need -fuse-ld=gold in the LDFLAGS. David While building ProjectCenter I see the use of clang -rdynamic, it looks like it's coming in from gnustep-config --objc-libs. Is this the "-r" you were mentioning before, and may be causing the problem with the frameworks/subprojects and resource bundle loading? Should we try to find some way to disable it? What is the recommended way to do this? Best, Patryk clang -shared -Wl,-soname,libProjectCenter.so.0 -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread -fexceptions -o ./ProjectCenter.framework/Versions/0.6.2/./libProjectCenter.so.0.6.2 obj/ ProjectCenter.obj/NSFramework_ProjectCenter.o obj/ProjectCenter.obj/PCBundleManager.m.o obj/ProjectCenter.obj/PCEditorManager.m.o obj/ProjectCenter.obj/PCMakefileFactory.m.o obj/ProjectCenter.obj/PCFileManager.m.o obj/ ProjectCenter.obj/PCAddFilesPanel.m.o obj/ProjectCenter.obj/PCFileCreator.m.o obj/ProjectCenter.obj/ PCSaveModified.m.o obj/ProjectCenter.obj/PCProjectManager.m.o obj/ProjectCenter.obj/PCProject.m.o obj/ ProjectCenter.obj/PCProjectWindow.m.o obj/ProjectCenter.obj/PCProjectInspector.m.o obj/ProjectCenter.obj/ PCProjectBuilder.m.o obj/ProjectCenter.obj/PCProjectBuilderOptions.m.o obj/ProjectCenter.obj/ PCProjectBuilderPanel.m.o obj/ProjectCenter.obj/PCProjectLauncher.m.o obj/ProjectCenter.obj/ PCProjectLauncherPanel.m.o obj/ProjectCenter.obj/PCProjectEditor.m.o obj/ProjectCenter.obj/PCProjectBrowser.m.o obj/ProjectCenter.obj/PCProjectLoadedFiles.m.o obj/ProjectCenter.obj/PCProjectLoadedFilesPanel.m.o obj/ ProjectCenter.obj/PCButton.m.o obj/ProjectCenter.obj/PCFileNameField.m.o obj/ProjectCenter.obj/PCFileNameIcon.m.o obj/ProjectCenter.obj/PCLogController.m.o obj/ProjectCenter.obj/PCAuxiliaryWindow.m.o -L../ ProjectCenter/./obj -L/home/patryk/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -lobjc -lgnustep-base -lgnustep-gui clang -shared -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread -fexceptions -o ./ProjectCe nter.debugger/./ProjectCenter ./obj/ProjectCenter.obj/PCDebugger.m.o ./obj/ProjectCenter.obj/PCDebuggerView.m. o ./obj/ProjectCenter.obj/PipeDelegate.m.o -L../../../Framework/ProjectCenter.framework/. -L/home/patryk/ GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -lgnustep-gui -lgnustep-base -lpthread -lobjc -lm clang -rdynamic -fuse-ld=/usr/bin/ld.gold -L/usr/local/lib -pthread -fexceptions -fobjc-runtime=gnuste p-2.0 -fblocks -o ProjectCenter.app/./ProjectCenter \ ./obj/ProjectCenter.obj/PCAppController.m.o ./obj/ProjectCenter.obj/PCInfoController.m.o ./obj/ProjectCenter.obj/PCMenuController.m.o ./obj/ProjectCenter.obj/PCPrefController.m.o ./obj/ProjectCenter.obj/ProjectCenter_main.m.o -L./Framework/ProjectCenter.framework/. -L/home/patryk/GNUstep/Library/Libraries -L/usr/GNUstep/Local/Library/Libraries -L/usr/GNUstep/System/Library/Libraries -lProjectCenter -lgnustep-gui -lgnustep-base -lpthread -lobjc -lm
Re: ProjectCenter running or building
On 06/01/2020 09:30, Riccaro Mottola wrote: There is a bug in BFD LD. Things that use ld -r in some situations (I have not been able to find a minimal test case, but base additions is one) have things stripped too early and so all of the Objective-C classes are removed. On my working setup on OpenBSD I explictely set bfd and this "fixed" for me the c++ abi issues. I used: LDFLAGS=-fuse-ld=bfd Interesting. Is LLD the default linker on OpenBSD? There are a couple of things on FreeBSD that I need to mark as LLD_UNSAFE and have them fall back to gold. BFD may work for them. At some point, I need to find reduced test cases for the LLD bugs: it works on almost everything and seems to fail on only some of the more complex cases (SOGo, for example), but I've not seen run-time failures, only link-time errors. David
Re: ProjectCenter running or building
On 05/01/2020 16:15, Patryk Laurent wrote: Do you think the bug is also is in ld.gold? During build, we set LD=/usr/bin/ld.gold (for example,https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46) Is $LD actually used to build? Most of the time, $CC is invoked as the linker, so you need -fuse-ld=gold in the LDFLAGS. David
Re: ProjectCenter running or building
Hi Riccardo, On 6 Jan 2020, at 10:26, Riccaro Mottola wrote: I can confirm this issue using the 2.0 runtime. LogPanel is not loaded. I don’t know if it is the same issue, but the inspectors of GWorkspace (being bundles as well I think) do not work using 2.0 runtime as well. Just for information. On my OpenBSD setup I am running now clang + liobjc2 (latest git) and of course ng-gnu-gnu. I do not have issues with ProjectCenter, it loads the log panel fine. Also GWorkspace loads inspector bundles correctly and I can view PDF files fine (which is the most critical of the content inspector, PDFKit having a C++ Bridge). PDFKit is latest SVN head and currently in "test". thank you for getting into this. It might be Patryk already asked the right questions. Because if you use the standard setup of GNUstep make and/or the libobjc2 v1.8 release tarball it is quite likey that you set up the older „ng“ GNUstep runtime versioned 1.x. So regarding your list of possible setups it should look be a little bit extended regarding options 4a and 4b afaik: 4a) clang + libobjc2 and make configured ng-gnu-gnu and set RUNTIME_VERSION=gnustep-1.9 (or 1.x). This one will build using older version of clang and is known to work with various linkers. You’ll find a reference setup here: https://github.com/plaurent/gnustep-build/blob/master/ubuntu-16.04-clang-6.0-runtime-1.9/GNUstep-buildon-ubuntu1604.sh (note clang 6 and RUNTIME_VERSION. We even did a checkout of the 1.9 tag even though I don’t know if this is necessary.) 4b) clang + libobjc and make configured ng-gnu-gnu, using master from GitHub and RUNTIME_VERSION=gnustep-2.0. This one is the new and cleaner version of the ng runtime David wrote at the end of 2018. Afaik it will only build and run using clang >= 8 and it will not run when linked using bdf or lld. You’ll find a reference setup here: https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-buildon-ubuntu1904.sh (note clang 8, RUNTIME_VERSION and the use of ld.gold). If I use setup 4a everything works without issues. The issues Patryk and I were talking about appear using setup 4b. Maybe you can check your setup against these instruction and see if you can reproduce our setup/issues? Thank you and good luck Johannes
Re: ProjectCenter running or building
Hi, On 2020-01-05 12:50:57 +0100 David Chisnall wrote: There is a bug in BFD LD. Things that use ld -r in some situations (I have not been able to find a minimal test case, but base additions is one) have things stripped too early and so all of the Objective-C classes are removed. On my working setup on OpenBSD I explictely set bfd and this "fixed" for me the c++ abi issues. I used: LDFLAGS=-fuse-ld=bfd and as written in another mail, GWorkspace and ProjectCenter seem fine for me. What is this bfd vs gold all about? Riccardo
Re: ProjectCenter running or building
Hi Johannes, On 2019-12-30 11:21:28 +0100 Johannes Brakensiek wrote: . > > I can confirm this issue using the 2.0 runtime. LogPanel is not loaded. I > don’t know if it is the same issue, but the inspectors of GWorkspace (being > bundles as well I think) do not work using 2.0 runtime as well. Just for information. On my OpenBSD setup I am running now clang + liobjc2 (latest git) and of course ng-gnu-gnu. I do not have issues with ProjectCenter, it loads the log panel fine. Also GWorkspace loads inspector bundles correctly and I can view PDF files fine (which is the most critical of the content inspector, PDFKit having a C++ Bridge). PDFKit is latest SVN head and currently in "test". Riccardo
Re: ProjectCenter running or building
Hi David, > On Jan 5, 2020, at 03:51, David Chisnall wrote: > > On 2 Jan 2020, at 20:50, Fred Kiefer wrote: >> >> from now on this is a clang issue and I am no longer of any help here. Maybe >> David has an idea what is going on? It would help to know which version of >> clang used to work and on which version it is failing. The next thing would >> be to write a minimal framework and an application using this to reproduce >> the issue. > > There is a bug in BFD LD. Things that use ld -r in some situations (I have > not been able to find a minimal test case, but base additions is one) have > things stripped too early and so all of the Objective-C classes are removed. Do you think the bug is also is in ld.gold? During build, we set LD=/usr/bin/ld.gold (for example, https://github.com/plaurent/gnustep-build/blob/master/ubuntu-19.10-clang-9.0-runtime-2.0/GNUstep-buildon-ubuntu1910.sh#L46) Or perhaps it’s possible the LD environment variable is being ignored somewhere? Patryk
Re: ProjectCenter running or building
On 5 Jan 2020, at 12:50, David Chisnall wrote: from now on this is a clang issue and I am no longer of any help here. Maybe David has an idea what is going on? It would help to know which version of clang used to work and on which version it is failing. The next thing would be to write a minimal framework and an application using this to reproduce the issue. There is a bug in BFD LD. Things that use ld -r in some situations (I have not been able to find a minimal test case, but base additions is one) have things stripped too early and so all of the Objective-C classes are removed. I’m quite sure that I linked everything using ld.gold. Same issue. Johannes
Re: ProjectCenter running or building
On 2 Jan 2020, at 20:50, Fred Kiefer wrote: > > from now on this is a clang issue and I am no longer of any help here. Maybe > David has an idea what is going on? It would help to know which version of > clang used to work and on which version it is failing. The next thing would > be to write a minimal framework and an application using this to reproduce > the issue. There is a bug in BFD LD. Things that use ld -r in some situations (I have not been able to find a minimal test case, but base additions is one) have things stripped too early and so all of the Objective-C classes are removed. David
Re: ProjectCenter running or building
I've been looking into subprojects and bundles, but it's not clear to me how to create a minimal (failing) test of this. At this point I am not sure how to proceed. On the bright side, writing a minimal test for frameworks worked, so it's not just a frameworks problem. Patryk > On Dec 29, 2019, at 6:21 AM, David Chisnall wrote: > > On 29 Dec 2019, at 13:16, Fred Kiefer wrote: >> >>> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass >>> PCProjectDocument not found > > Is this project using ld -r (I forget what GNUstep Make calls this - > subprojects?)? If so, it may be the same issue as Base Additions, which > can’t be linked with BFD LD. > > David >
Re: ProjectCenter running or building
Hi Fred and David, Quick update: I built a minimal framework and a test application and it ran fine under clang. However I didn't use/try to load anything from a resource bundle in the framework, so that's what I'll try next to see if it will fail. Patryk > On Jan 2, 2020, at 12:50 PM, Fred Kiefer wrote: > > > >> Am 02.01.2020 um 19:06 schrieb Patryk Laurent : >> >> >> It looks like the “name” in LLDB was referring to the binary’s name. So I >> placed an NSLog right before NSBundle.m:2280 to print out the local variable >> name and _frameworkVersion — which is null for all the classes being loaded, >> including “LogPanel”. Please see below. > > > Sorry Patryk, > from now on this is a clang issue and I am no longer of any help here. Maybe > David has an idea what is going on? It would help to know which version of > clang used to work and on which version it is failing. The next thing would > be to write a minimal framework and an application using this to reproduce > the issue. > > Fred
Re: ProjectCenter running or building
Hi Fred, > On Jan 2, 2020, at 15:50, Fred Kiefer wrote: > >> Am 02.01.2020 um 19:06 schrieb Patryk Laurent : >> >> ... >> _frameworkVersion — which is null for all the classes being loaded, >> including “LogPanel”. > > > Sorry Patryk, > from now on this is a clang issue and I am no longer of any help here. Maybe > David has an idea what is going on? It would help to know which version of > clang used to work and on which version it is failing. The next thing would > be to write a minimal framework and an application using this to reproduce > the issue. > > Fred Right, will proceed. Maybe we can add the minimal framework as a failing test for one of the repos. (But should that be in libs-base or libobjc2? Or perhaps even tools-make?) Patryk
Re: ProjectCenter running or building
> Am 02.01.2020 um 19:06 schrieb Patryk Laurent : > > > It looks like the “name” in LLDB was referring to the binary’s name. So I > placed an NSLog right before NSBundle.m:2280 to print out the local variable > name and _frameworkVersion — which is null for all the classes being loaded, > including “LogPanel”. Please see below. Sorry Patryk, from now on this is a clang issue and I am no longer of any help here. Maybe David has an idea what is going on? It would help to know which version of clang used to work and on which version it is failing. The next thing would be to write a minimal framework and an application using this to reproduce the issue. Fred
Re: ProjectCenter running or building
Hi Fred,
> On Dec 30, 2019, at 03:23, Fred Kiefer wrote:
>
> In your examples the name was „ProjectCenter“ not „LogPanel“. You need to
> continue your debugging until you get to that name. Only this resource seems
> to get loaded from a framework. For the other resources having a framework
> version of nil is correct.
>
> Fred
>
>>>
>>> The code in base doesn’t have any log statements that we could use. So this
>>> means you will have to switch to a debugger and run ProjectCenter with a
>>> breakpoint on NSBundle.m:2280 and wait until we get around with the name
>>> „LogPanel“ and see whether the framework version gets added correctly.
>
It looks like the “name” in LLDB was referring to the binary’s name. So I
placed an NSLog right before NSBundle.m:2280 to print out the local variable
name and _frameworkVersion — which is null for all the classes being loaded,
including “LogPanel”. Please see below.
Patryk
2019-12-30 19:22:28.531 ProjectCenter[18980:18980] name=Localizable,
_frameworkVersion=(null)
2019-12-30 19:22:28.533 ProjectCenter[18980:18980] name=localtime,
_frameworkVersion=(null)
2019-12-30 19:22:28.530 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.544 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.553 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.562 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.572 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.581 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.591 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.592 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.600 ProjectCenter[18980:18980] name=Locale,
_frameworkVersion=(null)
2019-12-30 19:22:28.614 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.629 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.644 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.835 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.835 ProjectCenter[18980:18980] name=Info,
_frameworkVersion=(null)
2019-12-30 19:22:28.836 ProjectCenter[18980:18980] name=nsmapping,
_frameworkVersion=(null)
2019-12-30 19:22:28.836 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
2019-12-30 19:22:28.837 ProjectCenter[18980:18980] name=Info,
_frameworkVersion=(null)
2019-12-30 19:22:28.837 ProjectCenter[18980:18980] name=nsmapping,
_frameworkVersion=(null)
2019-12-30 19:22:28.846 ProjectCenter[18980:18980] name=Info-gnustep,
_frameworkVersion=(null)
Error (objc-load):/usr/GNUstep/Local/Library/Themes/Rik.theme/Rik: undefined
symbol:
__objc_ivar_offset_NSWindow._f.{GSWindowFlagsType=b0I1b1I1b2I1b3I1b4I1b5I1b6I1b7I1b8I1b9I1b10I1b11I1b12I1b13I1b14I1b15I1b16I1b17I1b18I1b19I1b20I1b21I1b22I1b23I1b24I1b25I1b26I1b27I2b29I1b30I1b31I1b32I1b33I1b34I1b35I1}
Error (objc-load):/usr/GNUstep/Local/Library/Themes/Rik.theme/Rik: undefined
symbol:
__objc_ivar_offset_NSWindow._f.{GSWindowFlagsType=b0I1b1I1b2I1b3I1b4I1b5I1b6I1b7I1b8I1b9I1b10I1b11I1b12I1b13I1b14I1b15I1b16I1b17I1b18I1b19I1b20I1b21I1b22I1b23I1b24I1b25I1b26I1b27I2b29I1b30I1b31I1b32I1b33I1b34I1b35I1}
2019-12-30 19:22:28.853 ProjectCenter[18980:18980] name=ThemeColors,
_frameworkVersion=(null)
2019-12-30 19:22:28.857 ProjectCenter[18980:18980] name=ProjectCenter,
_frameworkVersion=(null)
2019-12-30 19:22:28.860 ProjectCenter[18980:18980] name=ProjectCenter,
_frameworkVersion=(null)
2019-12-30 19:22:28.862 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.863 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.864 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.864 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.865 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.866 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.867 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.867 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.868 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.869 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.870 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
2019-12-30 19:22:28.870 ProjectCenter[18980:18980] name=NSApplicationIcon,
_frameworkVersion=(null)
Re: ProjectCenter running or building
Hi ! On 12/29/19 2:16 PM, Fred Kiefer wrote: I just compiled ProjectCenter with gcc and it seems to be basically working there (I had to fix a few compiler warnings first but these should not be relevant for your issues). The NIB loading errors you are getting are strange. You could try to get a bit more information about the files it is trying to load by providing the argument „—GNU-Default=dflt“ when starting ProjectCenter. That way you could try to find out whether the gorm files are actually missing or could not be loaded. Thank you for your patches, Fred. I had a look at them and I don't see anything relevant - that is anything that could have caused real malfunctions. I just compiled with gcc too and it works as before :-P The missing NSDocumentClass classes are correct. Somebody set up a document definition in the Info.plist file for ProjectCenter but never bothered with providing the classes defined there. No idea how this was supposed to work. I'm unsure either. Perhaps they are defined only to allow the filetypes to be opened, or something is missing or misconfigured. However, it surely does not affect NIB loading, the warnings are there since a long time and PC works for me.ù Later in your log there are errors coming from GWorkspace, you should be looking into these separately. They worry me ... I hope we can understand them. R
Re: ProjectCenter running or building
Hi, On 12/30/19 11:21 AM, Johannes Brakensiek wrote: I can confirm this issue using the 2.0 runtime. LogPanel is not loaded. I don’t know if it is the same issue, but the inspectors of GWorkspace (being bundles as well I think) do not work using 2.0 runtime as well. this is to worry about! it needs to be investigated. Unfortunately, the laptop I have here which is running clang + libobc2 is not completing build on OpenBSD, there are linking issues which block me right now to try to reproduce this. Riccardo
Re: ProjectCenter running or building
Hi Patryk, On 12/29/19 4:01 AM, Patryk Laurent wrote: 2019-12-29 00:37:29.011 GWorkspace[10745:10745] File NSData.m: 287. In BOOL readContentsOfFile(NSString *, void **, off_t *, NSZone *) Open ((null)) attempt failed - bad path 2019-12-29 00:37:29.014 GWorkspace[10745:10745] File NSData.m: 287. In BOOL readContentsOfFile(NSString *, void **, off_t *, NSZone *) Open ((null)) attempt failed - bad path 2019-12-29 00:37:29.017 GWorkspace[10745:10745] File NSData.m: 287. In BOOL readContentsOfFile(NSString *, void **, off_t *, NSZone *) Open ((null)) attempt failed - bad path as Fred wrote, this is GWorkspace specific, but i want to investigate this. We should have a separate email discussion about this. Can you reproduce this error in GWorkspace alone without running ProjectCenter? May you be able to provide a stacktrace of this by putting a breakpoint so we can see where GWorkspace is complaining? Johannes mentions that there may be bundle problems with Inspectors, i want to check if there is GWorkspace specific code, maybe I can add better error handling and get a more meaningful error. Thank you & Happy New Year! Riccardo
Re: ProjectCenter running or building
Hello everyone, On 30 Dec 2019, at 9:23, Fred Kiefer wrote: Am 30.12.2019 um 01:17 schrieb Patryk Laurent : On December 29, 2019 at 12:31 PM, Fred Kiefer wrote: Thank you for your tests. I had a look into the NSBundle code in base and from that I think that we have an issue with frameworks here. Is clang supporting frameworks? The code in base doesn’t have any log statements that we could use. So this means you will have to switch to a debugger and run ProjectCenter with a breakpoint on NSBundle.m:2280 and wait until we get around with the name „LogPanel“ and see whether the framework version gets added correctly. I can confirm this issue using the 2.0 runtime. LogPanel is not loaded. I don’t know if it is the same issue, but the inspectors of GWorkspace (being bundles as well I think) do not work using 2.0 runtime as well. Johannes
Re: ProjectCenter running or building
In your examples the name was „ProjectCenter“ not „LogPanel“. You need to continue your debugging until you get to that name. Only this resource seems to get loaded from a framework. For the other resources having a framework version of nil is correct. Fred > Am 30.12.2019 um 01:17 schrieb Patryk Laurent : > > On December 29, 2019 at 12:31 PM, Fred Kiefer wrote: > >> Thank you for your tests. I had a look into the NSBundle code in base and >> from that I think that we have an issue with frameworks here. Is clang >> supporting frameworks? >> The code in base doesn’t have any log statements that we could use. So this >> means you will have to switch to a debugger and run ProjectCenter with a >> breakpoint on NSBundle.m:2280 and wait until we get around with the name >> „LogPanel“ and see whether the framework version gets added correctly. >> > > From within the debugger I am seeing that _frameworkVersion tends to be nil. > And I'm having trouble seeing the values of NSStrings... so maybe there's > something up. > > Patryk > > > (base) > patryk@wax:~/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app$ > lldb ./ProjectCenter > (lldb) target create "./ProjectCenter" > Current executable set to './ProjectCenter' (x86_64). > > (lldb) breakpoint set --file NSBundle.m --line 2280 > Breakpoint 1: no locations (pending). > WARNING: Unable to resolve breakpoint to any actual locations. > > (lldb) run > Process 3951 launched: > '/home/patryk/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app/ProjectCenter' > (x86_64) > 1 location added to breakpoint 1 > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = breakpoint 1.1 > frame #0: 0x77731997 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", > name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2283:7 >2280 NSString *rootPath; >2281 >2282 #if !defined(_WIN32) > -> 2283 if (_frameworkVersion) >2284 rootPath = [NSString stringWithFormat: @"%@/Versions/%@", [self > bundlePath], >2285 _frameworkVersion]; >2286 else > > (lldb) fr va _frameworkVersion > (NSString *) _frameworkVersion = nil > (lldb) n > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = step over > frame #0: 0x777319e5 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", > name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2288:16 >2285 _frameworkVersion]; >2286 else >2287 #endif > -> 2288 rootPath = [self bundlePath]; >2289 >2290 return [NSBundle _pathForResource: name >2291 ofType: extension > > (lldb) n > Process 3951 stopped > * thread #1, name = 'ProjectCenter', stop reason = step over > frame #0: 0x777319f4 libgnustep-base.so.1.27`-[NSBundle > pathForResource:ofType:inDirectory:](self=0x00683768, > _cmd=, name=0x77a8c978, extension=0xe1b34f3e802c, > subPath=0x) at NSBundle.m:2290:10 >2287 #endif >2288 rootPath = [self bundlePath]; >2289 > -> 2290 return [NSBundle _pathForResource: name >2291 ofType: extension >2292 inRootPath: rootPath >2293 inDirectory: subPath]; > > (lldb) fr va rootPath > (NSString *) rootPath = 0x006838a8 > (lldb)
Re: ProjectCenter running or building
Hi David, On December 29, 2019 at 6:21 AM, David Chisnall wrote: On 29 Dec 2019, at 13:16, Fred Kiefer wrote: 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass PCProjectDocument not found Is this project using ld -r (I forget what GNUstep Make calls this - subprojects?)? If so, it may be the same issue as Base Additions, which can’t be linked with BFD LD. Might what you are referring to be the "Modules" or "bundles" that this file pertains to? https://github.com/gnustep/apps-projectcenter/blob/master/Modules/GNUmakefile.bundles Patryk
Re: ProjectCenter running or building
Hi Fred, On December 29, 2019 at 12:31 PM, Fred Kiefer wrote: Thank you for your tests. I had a look into the NSBundle code in base and from that I think that we have an issue with frameworks here. Is clang supporting frameworks? The code in base doesn’t have any log statements that we could use. So this means you will have to switch to a debugger and run ProjectCenter with a breakpoint on NSBundle.m:2280 and wait until we get around with the name „LogPanel“ and see whether the framework version gets added correctly. From within the debugger I am seeing that _frameworkVersion tends to be nil. And I'm having trouble seeing the values of NSStrings... so maybe there's something up. Patryk (base) patryk@wax:~/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app$ lldb ./ProjectCenter (lldb) target create "./ProjectCenter" Current executable set to './ProjectCenter' (x86_64). (lldb) breakpoint set --file NSBundle.m --line 2280 Breakpoint 1: no locations (pending). WARNING: Unable to resolve breakpoint to any actual locations. (lldb) run Process 3951 launched: '/home/patryk/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter/ProjectCenter.app/ProjectCenter' (x86_64) 1 location added to breakpoint 1 Process 3951 stopped * thread #1, name = 'ProjectCenter', stop reason = breakpoint 1.1 frame #0: 0x77731997 libgnustep-base.so.1.27`-[NSBundle pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", name=0x77a8c978, extension=0xe1b34f3e802c, subPath=0x) at NSBundle.m:2283:7 2280 NSString *rootPath; 2281 2282 #if !defined(_WIN32) -> 2283 if (_frameworkVersion) 2284 rootPath = [NSString stringWithFormat: @"%@/Versions/%@", [self bundlePath], 2285 _frameworkVersion]; 2286 else (lldb) fr va _frameworkVersion (NSString *) _frameworkVersion = nil (lldb) n Process 3951 stopped * thread #1, name = 'ProjectCenter', stop reason = step over frame #0: 0x777319e5 libgnustep-base.so.1.27`-[NSBundle pathForResource:ofType:inDirectory:](self=0x00683768, _cmd="-", name=0x77a8c978, extension=0xe1b34f3e802c, subPath=0x) at NSBundle.m:2288:16 2285 _frameworkVersion]; 2286 else 2287 #endif -> 2288 rootPath = [self bundlePath]; 2289 2290 return [NSBundle _pathForResource: name 2291 ofType: extension (lldb) n Process 3951 stopped * thread #1, name = 'ProjectCenter', stop reason = step over frame #0: 0x777319f4 libgnustep-base.so.1.27`-[NSBundle pathForResource:ofType:inDirectory:](self=0x00683768, _cmd=, name=0x77a8c978, extension=0xe1b34f3e802c, subPath=0x) at NSBundle.m:2290:10 2287 #endif 2288 rootPath = [self bundlePath]; 2289 -> 2290 return [NSBundle _pathForResource: name 2291 ofType: extension 2292 inRootPath: rootPath 2293 inDirectory: subPath]; (lldb) fr va rootPath (NSString *) rootPath = 0x006838a8 (lldb)
Re: ProjectCenter running or building
Thank you for your tests. I had a look into the NSBundle code in base and from
that I think that we have an issue with frameworks here. Is clang supporting
frameworks?
The code in base doesn’t have any log statements that we could use. So this
means you will have to switch to a debugger and run ProjectCenter with a
breakpoint on NSBundle.m:2280 and wait until we get around with the name
„LogPanel“ and see whether the framework version gets added correctly.
Fred
> Am 29.12.2019 um 21:10 schrieb Patryk Laurent :
>
> On Dec 29, 2019, at 11:16, Fred Kiefer wrote:
>>> ...
>>
>> Looks like things go wrong earlier than I thought. Could you try with the
>> argument „—GNU-Debug=NIB“ and only report back the results shortly before
>> „PCLogController[init]: error loading NIB file!“?
>>
>
> Here is the NIB log:
>
> 2019-12-29 19:58:04.303 ProjectCenter[20701:20701] Path for NIB file
> ProjectCenter.gorm
> 2019-12-29 19:58:04.309 ProjectCenter[20701:20701] Did not find NIB resource
> ProjectCenter.gorm
> 2019-12-29 19:58:04.313 ProjectCenter[20701:20701] Path for NIB file
> ProjectCenter.gorm
> 2019-12-29 19:58:04.339 ProjectCenter[20701:20701] Path for NIB file LogPanel
> 2019-12-29 19:58:04.339 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.340 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.341 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.342 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.343 ProjectCenter[20701:20701] Did not find NIB resource
> LogPanel
> 2019-12-29 19:58:04.343 ProjectCenter[20701:20701] Path for NIB file LogPanel
> 2019-12-29 19:58:04.344 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.344 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.345 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.346 ProjectCenter[20701:20701] Checking type LogPanel
> 2019-12-29 19:58:04.347 ProjectCenter[20701:20701] Did not find NIB resource
> LogPanel
> 2019-12-29 19:58:04.347 ProjectCenter[20701:20701] PCLogController[init]:
> error loading NIB file!
>>
>> From looking at the code in NSBundleAdditions.m I would expect that the gore
>> file isn’t found. For me that NIB file is located at
>> „/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm“.
>> Perhaps you should check whether a directory exists there and what it
>> contains.
>
>
> The directory is indeed there, and when I look inside that directory I find
> the usual suspects (data.classes, data.info, and objects.gorm). But I don’t
> see a definition for a “LogPanel” object in data.classes, it only contains
> PCLogController — would we expect LogPanel to be in there?
>
> patryk@pinebook:~/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app$
> ls -l
> /usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm/
> total 12
> -rwxrwxr-x 1 patryk patryk 178 Dec 29 16:54 data.classes
> -rwxrwxr-x 1 patryk patryk 210 Dec 29 16:54 data.info
> -rwxrwxr-x 1 patryk patryk 2226 Dec 29 16:54 objects.gorm
>
> patryk@pinebook:/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm$
> cat data.classes
> {
>"## Comment" = "Do NOT change this file, Gorm maintains it";
>PCLogController = {
> Actions = (
> );
> Outlets = (
> panel,
> textView
> );
> Super = NSObject;
>};
> }
>
> Patryk
>
>
>
>
>
Re: ProjectCenter running or building
Hi Fred,
On Dec 29, 2019, at 11:16, Fred Kiefer wrote:
>> ...
>
> Looks like things go wrong earlier than I thought. Could you try with the
> argument „—GNU-Debug=NIB“ and only report back the results shortly before
> „PCLogController[init]: error loading NIB file!“?
>
Here is the NIB log:
2019-12-29 19:58:04.303 ProjectCenter[20701:20701] Path for NIB file
ProjectCenter.gorm
2019-12-29 19:58:04.309 ProjectCenter[20701:20701] Did not find NIB resource
ProjectCenter.gorm
2019-12-29 19:58:04.313 ProjectCenter[20701:20701] Path for NIB file
ProjectCenter.gorm
2019-12-29 19:58:04.339 ProjectCenter[20701:20701] Path for NIB file LogPanel
2019-12-29 19:58:04.339 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.340 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.341 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.342 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.343 ProjectCenter[20701:20701] Did not find NIB resource
LogPanel
2019-12-29 19:58:04.343 ProjectCenter[20701:20701] Path for NIB file LogPanel
2019-12-29 19:58:04.344 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.344 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.345 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.346 ProjectCenter[20701:20701] Checking type LogPanel
2019-12-29 19:58:04.347 ProjectCenter[20701:20701] Did not find NIB resource
LogPanel
2019-12-29 19:58:04.347 ProjectCenter[20701:20701] PCLogController[init]: error
loading NIB file!
>
> From looking at the code in NSBundleAdditions.m I would expect that the gore
> file isn’t found. For me that NIB file is located at
> „/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm“.
> Perhaps you should check whether a directory exists there and what it
> contains.
The directory is indeed there, and when I look inside that directory I find the
usual suspects (data.classes, data.info, and objects.gorm). But I don’t see a
definition for a “LogPanel” object in data.classes, it only contains
PCLogController — would we expect LogPanel to be in there?
patryk@pinebook:~/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app$
ls -l
/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm/
total 12
-rwxrwxr-x 1 patryk patryk 178 Dec 29 16:54 data.classes
-rwxrwxr-x 1 patryk patryk 210 Dec 29 16:54 data.info
-rwxrwxr-x 1 patryk patryk 2226 Dec 29 16:54 objects.gorm
patryk@pinebook:/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm$
cat data.classes
{
"## Comment" = "Do NOT change this file, Gorm maintains it";
PCLogController = {
Actions = (
);
Outlets = (
panel,
textView
);
Super = NSObject;
};
}
Patryk
Re: ProjectCenter running or building
> Am 29.12.2019 um 18:30 schrieb Patryk Laurent : > >> >> On Dec 29, 2019, at 09:17, Fred Kiefer wrote: >> this should have been „—GNU-Debug=dflt" > > Indeed — I see a lot more output now[1]. What do you make of this? It looks > like many different instances of PCLogController throughout the app are > failing to initialize / load NIBs. Perhaps this is what is preventing > ProjectCenter from showing content? The other .gorm files are appear to be > loading fine... Looks like things go wrong earlier than I thought. Could you try with the argument „—GNU-Debug=NIB“ and only report back the results shortly before „PCLogController[init]: error loading NIB file!“? From looking at the code in NSBundleAdditions.m I would expect that the gore file isn’t found. For me that NIB file is located at „/usr/GNUstep/Local/Library/Frameworks/ProjectCenter.framework/Versions/0.6.2/Resources/English.lproj/LogPanel.gorm“. Perhaps you should check whether a directory exists there and what it contains. Fred
Re: ProjectCenter running or building
Hi Fred, > On Dec 29, 2019, at 09:17, Fred Kiefer wrote: > >>> this should have been „—GNU-Debug=dflt" Indeed — I see a lot more output now[1]. What do you make of this? It looks like many different instances of PCLogController throughout the app are failing to initialize / load NIBs. Perhaps this is what is preventing ProjectCenter from showing content? The other .gorm files are appear to be loading fine... Patryk [1] 2019-12-29 17:22:58.580 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: SystemPreferences 2019-12-29 17:22:58.586 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: ProjectCenter 2019-12-29 17:22:58.615 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: NSGlobalDomain 2019-12-29 17:22:58.617 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: NSGeometry1 2019-12-29 17:22:58.617 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: MinimalApp 2019-12-29 17:22:58.617 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: DemoTable 2019-12-29 17:22:58.617 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: GWorkspace 2019-12-29 17:22:58.618 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: Gorm 2019-12-29 17:22:58.618 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: GNUMail 2019-12-29 17:22:58.618 ProjectCenter[19693:19693] File NSUserDefaults.m: 2427. In [NSUserDefaults -_readDefaults] domain name: Terminal 2019-12-29 17:22:58.730 ProjectCenter[19693:19693] Loading Backend from /usr/GNUstep/Local/Library/Bundles/libgnustep-back-028.bundle 2019-12-29 17:22:58.749 ProjectCenter[19693:19693] Initializing GNUstep x11 backend. 2019-12-29 17:22:58.755 ProjectCenter[19693:19693] Opened display :0.0, display 0 screen 0 ProjectCenter[19693:19693] Destroying GS Context 2019-12-29 17:22:59.150 ProjectCenter[19693:19693] Loading model `/home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/English.lproj/ProjectCenter.gorm'... 2019-12-29 17:22:59.151 ProjectCenter[19693:19693] Loading Gorm `/home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/English.lproj/ProjectCenter.gorm'... 2019-12-29 17:22:59.151 ProjectCenter[19693:19693] Loaded data from /home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/English.lproj/ProjectCenter.gorm/objects.gorm... 2019-12-29 17:22:59.152 ProjectCenter[19693:19693] Loaded data from /home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/English.lproj/ProjectCenter.gorm... 2019-12-29 17:22:59.152 ProjectCenter[19693:19693] Invoking unarchiver 2019-12-29 17:22:59.179 ProjectCenter[19693:19693] PCLogController[init]: error loading NIB file! 2019-12-29 17:22:59.181 ProjectCenter[19693:19693] Loading model `/home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/Misc.preferences/Resources/MiscPrefs.gorm'... 2019-12-29 17:22:59.181 ProjectCenter[19693:19693] Loading Gorm `/home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/Misc.preferences/Resources/MiscPrefs.gorm'... 2019-12-29 17:22:59.182 ProjectCenter[19693:19693] Loaded data from /home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/Misc.preferences/Resources/MiscPrefs.gorm/objects.gorm... 2019-12-29 17:22:59.182 ProjectCenter[19693:19693] Loaded data from /home/patryk/Desktop/gnustep-build/ubuntu-16.04-clang-9.0-runtime-2.0-ARM/GNUstep-build/apps-projectcenter/ProjectCenter.app/Resources/Misc.preferences/Resources/MiscPrefs.gorm... 2019-12-29 17:22:59.183 ProjectCenter[19693:19693] Invoking unarchiver 2019-12-29 17:22:59.301 ProjectCenter[19693:19693] Calling awakeWithContext 2019-12-29 17:22:59.303 ProjectCenter[19693:19693] final candidate path is: /usr/local/bin/gdb 2019-12-29 17:22:59.303 ProjectCenter[19693:19693] final candidate path is: /usr/bin/gdb 2019-12-29 17:22:59.303 ProjectCenter[19693:19693] final candidate path is: /bin/gdb 2019-12-29 17:22:59.303 ProjectCenter[19693:19693] Debugger tool found: (null) 2019-12-29 17:22:59.315 ProjectCenter[19693:19693] PCLogController[init]: error loading NIB file! 2019-12-29 17:22:59.316 ProjectCenter[19693:19693]
Re: ProjectCenter running or building
> Am 29.12.2019 um 18:10 schrieb Patryk Laurent : > >> On Dec 29, 2019, at 05:16, Fred Kiefer wrote: >> >>> Am 29.12.2019 um 04:01 schrieb Patryk Laurent : >>> >>> controllers, etc. Does anyone know how to solve these NIB errors? See >>> messages below[1]. >> >> The NIB loading errors you are getting are strange. You could try to get a >> bit more information about the files it is trying to load by providing the >> argument „—GNU-Default=dflt“ when starting ProjectCenter. That way you could >> try to find out whether the gorm files are actually missing or could not be >> loaded. > > There is no change in the output, same NIB loading errors with the argument > as without it. I have run with both ./ProjectCenter --GNU-Default=dflt in > the .app directory, or with openapp ProjectCenter.app --GNU-Default=dflt. Sorry, my fault, this should have been „—GNU-Debug=dflt" > (Is either of these the right way to provide the argument? I’m wondering if > the argument is actually being picked up. There is no indication.) > > I do see the .gorm files in the Resources/ directory. > > Interestingly I seem to get the same NIB loading error in ProjectCenter when > trying to re-open the project that I created with ProjectCenter. > > I haven’t dug into the code yet much, I suppose we need to try to print out > the .gorm filepaths it’s trying to load from, and/or see if we can insert > some more informative error messages?
Re: ProjectCenter running or building
Hi Patryk, I'm not entirely sure, but it's possible that Fred meant to say "--GNU-Debug" instead of "--GNU-Default", which controls debug messages from NSDebugLog() and friends. Cheers, Niels On 29.12.19 18:10, Patryk Laurent wrote: > Hi Fred, > >> On Dec 29, 2019, at 05:16, Fred Kiefer wrote: >> >>> Am 29.12.2019 um 04:01 schrieb Patryk Laurent : >>> >>> controllers, etc. Does anyone know how to solve these NIB errors? See >>> messages below[1]. >> >> The NIB loading errors you are getting are strange. You could try to get a >> bit more information about the files it is trying to load by providing the >> argument „—GNU-Default=dflt“ when starting ProjectCenter. That way you could >> try to find out whether the gorm files are actually missing or could not be >> loaded. > > There is no change in the output, same NIB loading errors with the argument > as without it. I have run with both ./ProjectCenter --GNU-Default=dflt in > the .app directory, or with openapp ProjectCenter.app --GNU-Default=dflt. > > (Is either of these the right way to provide the argument? I’m wondering if > the argument is actually being picked up. There is no indication.) > > I do see the .gorm files in the Resources/ directory. > > Interestingly I seem to get the same NIB loading error in ProjectCenter when > trying to re-open the project that I created with ProjectCenter. > > I haven’t dug into the code yet much, I suppose we need to try to print out > the .gorm filepaths it’s trying to load from, and/or see if we can insert > some more informative error messages? > > Patryk > > > > > > >
Re: ProjectCenter running or building
Hi Fred, > On Dec 29, 2019, at 05:16, Fred Kiefer wrote: > >> Am 29.12.2019 um 04:01 schrieb Patryk Laurent : >> >> controllers, etc. Does anyone know how to solve these NIB errors? See >> messages below[1]. > > The NIB loading errors you are getting are strange. You could try to get a > bit more information about the files it is trying to load by providing the > argument „—GNU-Default=dflt“ when starting ProjectCenter. That way you could > try to find out whether the gorm files are actually missing or could not be > loaded. There is no change in the output, same NIB loading errors with the argument as without it. I have run with both ./ProjectCenter --GNU-Default=dflt in the .app directory, or with openapp ProjectCenter.app --GNU-Default=dflt. (Is either of these the right way to provide the argument? I’m wondering if the argument is actually being picked up. There is no indication.) I do see the .gorm files in the Resources/ directory. Interestingly I seem to get the same NIB loading error in ProjectCenter when trying to re-open the project that I created with ProjectCenter. I haven’t dug into the code yet much, I suppose we need to try to print out the .gorm filepaths it’s trying to load from, and/or see if we can insert some more informative error messages? Patryk
Re: ProjectCenter running or building
On 29 Dec 2019, at 13:16, Fred Kiefer wrote: > >> 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass >> PCProjectDocument not found Is this project using ld -r (I forget what GNUstep Make calls this - subprojects?)? If so, it may be the same issue as Base Additions, which can’t be linked with BFD LD. David
Re: ProjectCenter running or building
> Am 29.12.2019 um 04:01 schrieb Patryk Laurent : > > From master: I can successfully build ProjectCenter from master on the repo, > but when I run it I get multiple errors about NIBs not being loaded, > NSDocumentClasses not being found, and no editor appears. On the bright > side, the template application gets created and I can open the .gorm file > with Gorm. But I can't get back to ProjectCenter to add new controllers, > etc. Does anyone know how to solve these NIB errors? See messages below[1]. I just compiled ProjectCenter with gcc and it seems to be basically working there (I had to fix a few compiler warnings first but these should not be relevant for your issues). The NIB loading errors you are getting are strange. You could try to get a bit more information about the files it is trying to load by providing the argument „—GNU-Default=dflt“ when starting ProjectCenter. That way you could try to find out whether the gorm files are actually missing or could not be loaded. The missing NSDocumentClass classes are correct. Somebody set up a document definition in the Info.plist file for ProjectCenter but never bothered with providing the classes defined there. No idea how this was supposed to work. Later in your log there are errors coming from GWorkspace, you should be looking into these separately. Hope this helps, Fred > [1] Runtime errors while running ProjectCenter from master: > (base) > patryk@wax:~/gnustep-build/ubuntu-19.04-clang-8.0-runtime-2.0/GNUstep-build/apps-projectcenter$ > openapp ProjectCenter > 2019-12-29 00:35:39.628 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:35:39.644 ProjectCenter[10666:10666] final candidate path is: > /usr/local/bin/gdb > 2019-12-29 00:35:39.644 ProjectCenter[10666:10666] final candidate path is: > /usr/bin/gdb > 2019-12-29 00:35:39.644 ProjectCenter[10666:10666] Debugger tool found: > /usr/bin/gdb > 2019-12-29 00:35:39.646 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:35:39.651 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:35:39.663 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:35:39.670 ProjectCenter[10666:10666] final candidate path is: > /usr/local/bin/gmake > 2019-12-29 00:35:39.670 ProjectCenter[10666:10666] final candidate path is: > /usr/bin/gmake > 2019-12-29 00:35:39.670 ProjectCenter[10666:10666] final candidate path is: > /usr/local/bin/make > 2019-12-29 00:35:39.670 ProjectCenter[10666:10666] final candidate path is: > /usr/bin/make > 2019-12-29 00:35:39.670 ProjectCenter[10666:10666] Build tool found: > /usr/bin/make > 2019-12-29 00:35:39.671 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:35:39.702 ProjectCenter[10666:10666] NSDocumentClass > PCProjectDocument not found > 2019-12-29 00:35:39.703 ProjectCenter[10666:10666] NSDocumentClass > PCProjectDocument not found > 2019-12-29 00:35:39.703 ProjectCenter[10666:10666] NSDocumentClass > PCClassDocument not found > 2019-12-29 00:35:39.703 ProjectCenter[10666:10666] NSDocumentClass > PCClassDocument not found > 2019-12-29 00:35:39.703 ProjectCenter[10666:10666] NSDocumentClass > PCHeaderDocument not found > 2019-12-29 00:35:39.703 ProjectCenter[10666:10666] NSDocumentClass > PCCDocument not found > 2019-12-29 00:35:56.979 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:36:00.778 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:36:00.779 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:36:00.779 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:36:00.781 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:09.013 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:11.689 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:11.689 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:11.690 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:11.691 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:28.728 ProjectCenter[10666:10666] PCLogController[init]: > error loading NIB file! > 2019-12-29 00:37:29.011 GWorkspace[10745:10745] File NSData.m: 287. In BOOL > readContentsOfFile(NSString *, void **, off_t *, NSZone *) Open ((null)) > attempt failed - bad path > 2019-12-29 00:37:29.014 GWorkspace[10745:10745] File NSData.m: 287. In BOOL > readContentsOfFile(NSString *, void **, off_t *, NSZone *) Open ((null)) > attempt failed - bad path > 2019-12-29 00:37:29.017 GWorkspace[10745:10745] File
Re: ProjectCenter running or building
> Am 29.12.2019 um 11:19 schrieb David Chisnall : > > On 29 Dec 2019, at 03:01, Patryk Laurent wrote: >> >> ./Framework/ProjectCenter.framework/./libProjectCenter.so: error: undefined >> reference to '__objc_ivar_offset_NSView._tracking_rects.' > > It looks as if PC is using a private NSView ivar. This will need to have to > change to using reflection APIs that Gorm required. The code of PCButton did contain its own implementation of tool tips. Riccardo removed that code more than half a year ago as we have a better implementation within gui. This is why master compiles without that issue. We should try to make a new release of ProjectCenter to have this change available for everybody. But first we need to look into the other issue Patryk reported.
Re: ProjectCenter running or building
On 29 Dec 2019, at 03:01, Patryk Laurent wrote: > > ./Framework/ProjectCenter.framework/./libProjectCenter.so: error: undefined > reference to '__objc_ivar_offset_NSView._tracking_rects.' It looks as if PC is using a private NSView ivar. This will need to have to change to using reflection APIs that Gorm required. David
