Re: building a self-contained deployable gnustep [cont]

[Richard Frith-Macdonald]

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.