discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Niels Grewe
Subject: Re: building a self-contained deployable gnustep [cont]
Date: Mon, 17 Oct 2011 15:27:23 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111005 Icedove/3.1.15

Am 17.10.2011 14:09, schrieb Julian Mayer:
>>>
>>> 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. 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?
> 
> 
> 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:
> 
> address@hidden:~/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:
> address@hidden:~/Desktop/GNUstepTest/HelloWorld.app$ ls Bundles/
> GSPrinting  libgmodel.bundle  libgnustep-back-021.bundle  TextConverters
> 
> i've tried stuffing a GNUstep.conf file in the helloworld.app bundle as well 
> - didn't change a thing:
> 
> GNUSTEP_SYSTEM_ROOT=.
> GNUSTEP_LOCAL_ROOT=.
> GNUSTEP_NETWORK_ROOT=.
> [etc]
> 
> do you have an idea here, or should i modify initialize_gnustep_backend() to 
> print out the path where it is searching for the backend to get more 
> information?
> 
> 
> 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:
> 
> address@hidden:~/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));

That's glibc using __block as a variable name where clang treats it as a
storage specifier. Here's the workaround that Quentin came up with for
the same issue in gnustep-base:

#ifdef HAVE_UNISTD_H
#ifdef __block
/* Turn off Clang built-in __block */
#undef __block
#endif
#define __block __gs_unistd_block
#include <unistd.h>
#undef __block
#endif


> 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.

Hmm. That odd. For me `PREFIX=/tmp/test make install' installs libobjc2
into /tmp/test.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]