On 17 Oct 2011, at 13:09, Julian Mayer wrote: >>> >>> Anyway, I've just spent some time trying to make things simpler by >>> providing templates for standalone deployment (will probably need further >>> tweaking, and I haven't documented it yet though) ... >>> >>> I >> I tried further testing with a gui app, and encountered an error in the >> standalone.conf template, which fixed in svn. >> >> cd make >> ./configure --with-layout=standalone >> make install >> . ~/standalone/Makefile/GNUstep.sh >> cd ../base >> ./configure --with-config-file=./ --with-default-config=standalone.conf >> make install >> cd ../gui >> make install >> cd ../back >> make install >> >> that puts the gnustep core packages into ~/standalone ... then you just need >> to copy that wherever you want it inside your app wrapper, and set >> LD_LIBRARY_PATH > > hello richard > > thanks for your help - i definitely didn't know to use the standalone layout > ... the "Relocateable Packages" section in the documentation also didn't > mention it.
No ... it tells you how to write your own layout. I added the standalone layout just so you don't need to write your own ... it may not be the layout you'd actually prefer, but it's the kind of thing people have done in the pas for standalone mswindows packages. > thanks too for reminding me about GNUSTEP_CONFIG_FILE, i am ignoring this for > now since you said the only thing the binary really should need is the proper > LD_LIBRARY_PATH. > > i've updated and rebuilt gnustep in the way you specified and verified that > it works when used from its installed location. one thing i am curious about, > you previously mentioned to use "--with-config-file=./GNUstep.conf" and now > "--with-config-file=./" ...are they equivalent? Not quite ... --with-config-file=./GNUstep.conf means read the GNUstep.conf,file in the same directory as the base library, and use the information from it --with-config-file=./ means treat the directory containing the base library as the location of the config file, but don't read/use it ... use the default paths built in when base was configured Both will make things relocatable, but one lets you reconfigure relative locations *after* building base and the other requires them to have been configured beforehand. > > nevertheless, launching the rebuilt helloworld app with the standalone folder > contents embedded still doesn't work. i've moved the standalone folder to > another location to be sure it doesn't get picked up, copied its contents to > the rebuilt helloworld app, switched to another terminal to be sure the > environment variables are clean and: > > notroot@ubuntu:~/Desktop/GNUstepTest/HelloWorld.app$ > LD_LIBRARY_PATH=/home/notroot/Desktop/GNUstepTest/HelloWorld.app ./HelloWorld > 2011-10-16 21:32:26.305 HelloWorld[6593] Did not find correct version of > backend (libgnustep-back-021.bundle), falling back to std > (libgnustep-back.bundle). > 2011-10-16 21:32:26.305 HelloWorld[6593] NSApplication.m:304 Assertion > failed in BOOL initialize_gnustep_backend(). Unable to find backend back > ./HelloWorld: Uncaught exception NSInternalInconsistencyException, reason: > NSApplication.m:304 Assertion failed in BOOL initialize_gnustep_backend(). > Unable to find backend back > > of course the backend is there: > notroot@ubuntu:~/Desktop/GNUstepTest/HelloWorld.app$ ls Bundles/ > GSPrinting libgmodel.bundle libgnustep-back-021.bundle TextConverters Ah ... the templates I set up and the example I emailed are for the standalone folder being insider your app folder. Judging by the LD_LIBRARY_PATH you set, It looks like you've put the *content* of the standalone folder insider the app folder, rather than the standalone folder itsself. You would want LD_LIBRARY_PATH=/home/notroot/Desktop/GNUstepTest/HelloWorld.app/standalone Of course, you can use a different layout designed to have things directly inside your app folder rather than a level down if you like, but I did the templates for a 'standalone' folder so that anyone using it won't get problems with resources from GNUstep conflicting with their own apps resources. > btw when rebuilding gnustep i've encountered this problems: > > i wanted to try out the nonfragile option to make/libobjc2 but building > libobjc2 1.5.1 with the non-fragile option yielded this: > > notroot@ubuntu:~/Desktop/libobjc2-1.5.1$ clang arc.m -c -MMD -MP > -DTYPE_DEPENDENT_DISPATCH -D__OBJC_RUNTIME_INTERNAL__=1 -D_XOPEN_SOURCE=500 > -DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing > -fobjc-nonfragile-abi -D_NONFRAGILE_ABI -pthread -fPIC -Wall -DGSWARN > -DGSDIAGNOSE -Wno-import -g -O2 -fgnu-runtime -std=gnu99 -g -fexceptions > -Wno-unused-function -O3 -std=gnu99 -g -fexceptions -Wno-unused-function -O3 > -I. -I/home/notroot/GNUstep/Library/Headers > -I/home/notroot/standalone/include -o obj/libobjc.obj/arc.m.o > In file included from arc.m:400: > In file included from ./hash_table.h:21: > /usr/include/unistd.h:1128:35: error: __block attribute not allowed, only > allowed on local variables > extern void encrypt (char *__block, int __edflag) __THROW __nonnull ((1)); > ^ > > i wanted to switch to the SVN trunk version of libobjc2 to see if the problem > is gone there, but it doesn't use GNUmakefiles anymore - and unconditionally > installs into /usr/local. thats not fine for me since i need the libobj2 > shipped in the standalone folder since my users won't have it. i think > libobjc2 trunk should still have an option to be deployable - i don't care if > its with an option to just build statically or by still installing into the > gnustep path. I guess you should file a libobjc2 bug for David to fix this ... probably he meant to make it easy for libobjc2 to be used by people outside gnustep, but it does seem perverse if it won't install/integrate well with gnustep any more. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
