Hi Richard,
thanks for the response. I've played a bit further and looks like this is
enough to set up GNUstep. Turns out that GSPrivateExecutablePath() doesn't
need modification.
NSString * cmdline = [NSString stringWithContentsOfFile: [NSString
stringWithFormat: @"/proc/%d/cmdline", getpid()]];
NSString * identifier = [[cmdline componentsSeparatedByString: @" "]
objectAtIndex: 0];
NSString * home = [NSString stringWithFormat: @"/data/data/%@",
identifier];
NSString * exe = [NSString stringWithFormat: @"%@/exe", home];
FILE * f = fopen([exe UTF8String], "w"); if(f) fclose(f);
NSString * path = [NSString stringWithFormat: @"PATH=%@", home];
NSString * home2 = [NSString stringWithFormat: @"HOME=%@", home];
const char* argv[1] = { [exe UTF8String] };
const char* env[4] = { "USER=android", [home UTF8String], [path
UTF8String], NULL };
GSInitializeProcess(1, argv, env);
I've chucked this in the initialization function (which, with the example
for using NativeActivity class provided in documentation, is
android_main()).
I've hoped this might help with NSMutableDictionary issues (that something
gets initialized) but apparently that isn't the case. Oh well.
On Thu, Jun 12, 2014 at 11:44 AM, Richard Frith-Macdonald <[email protected]>
wrote:
>
> On 12 Jun 2014, at 11:27, Ivan Vučica <[email protected]> wrote:
>
> > Hi,
> >
> > as you may know, any native code in Android GUI applications must be
> delivered as a shared object.
> >
> > So, there is no main() and there is no executable. There is also no
> bundle that the binary can be delivered in, and we might only fake HOME by
> providing the application's data directory. (I temporarily use /.)
> >
> > Based on previous discussions on this list, I've thrown together a fake
> call to GSInitializeProcess():
> >
> > const char* argv[1] = { "gnustep-app" };
> > const char* env[3] = { "USER=android", "HOME=/", NULL };
> > GSInitializeProcess(1, argv, env);
> >
> > Sadly:
> >
> > I/gnustep-app( 6739): 2014-06-12 10:25:35.191 gnustep-app[6739]
> NSBundle.m:396 Assertion failed in NSString *GSPrivateExecutablePath().
> NSInternalInconsistencyException
> >
> > Any existing approach to dealing with there-is-no-executable situation?
>
> I don't know of any (and would be surprised if anyone has done it).
>
> The GSPrivateExecutablePath() function to locate the running executable is
> key to finding relative/relocatable configuration information
> (GNUstep.conf) and therefore finding where the program is installed and
> hence where/how to handle the parts of the OpenStep/Cocoa API dealing with
> file/resource locations.
>
> So ... I imagine we actually need specific new code in base to handle this
> for android.
> I don't know the android APIs at all but I do know (from using a phone and
> reading a bit) that.
> 1. apps normally store their data on the internal phone memory, but can
> usualy be moved to the sd card
> 2. in the latest android release, the app data on the sd card is forced to
> live in a fixed folder location
>
> That suggests to me that android must provide an api for determining what
> folder the app and its data lives in ... so I guess
> GSPrivateExecutablePath() would need to be modified to point to a
> dummy/fake executable within that folder, and anything using it would need
> to be modified to cope with the fact that the executable itsself might not
> actually be there; probably little to do since I guess mostly code will
> likely just remove the last path component (the name of the executable) and
> use the remainder as a starting point to find resources.
> The base library could then be configured with default relative paths
> (from GNUstep.conf) and would locate resources using those relative paths.
>
> On the other hand, it might make more sense to change all the bundle/path
> utilities code to use the corresponing android APIs (probably a lot more
> work though).
>
>
>
--
Ivan Vučica
[email protected]
_______________________________________________
Discuss-gnustep mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
