Re: [Mono-dev] Need help building Mono under Snow Leopard
You can also autogen/configure with the --with-glib=embedded to get around that
depenedency. I'm compiling on Snow Leopard using that.
Koush
On Dec 3, 2009, at 1:11 PM, ptr2009 wrote:
hey all
I am trying to build mono under Snow Leopard. I have the the 64bit Xcode
3.2.1 installed.
Here is what I have tried.
Followed instructions from http://www.mono-project.com/Compiling_Mono_on_OSX
What I had to differently from the page was
1) In building glib I cd'ed to glib directory instead of pkg-config. I am
assuming it was a typo on the website
2) glib complained about libiconv so I downloaded and compiled
libiconv-1.13.1 and installed under MONO_PREFIX directory.
3) I added these three extra variables to my setup-mono script as per some
previous posts in this forum
CFLAGS=-arch i386 -D_XOPEN_SOURCE
LDFLAGS=-arch i386
CXXFLAGS=$CFLAGS
I have been able to successfully build all the necessary dependencies to
build mono.
Afters I tried building the mono 2.4.2.3 tar source but I get the following
error
--
UNMAP -DGetCurrentProcess=MonoGetCurrentProcess
-DGetCurrentThread=MonoGetCurrentThread -DCreateEvent=MonoCreateEvent -g -MT
allchblk.lo -MD -MP -MF .deps/allchblk.Tpo -c allchblk.c -fno-common -DPIC
-o .libs/allchblk.o
In file included from ./include/private/gc_priv.h:66,
from allchblk.c:19:
./include/private/gcconfig.h:499: error: expected identifier or ‘(’ before
‘--’ token
make[3]: *** [allchblk.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
I have also tried the instructions on Compiling_Mono_FROM_SVN. But I get the
following error
-
rm -f es.gmo /Users/ptrajkumar/monobin/bin/msgfmt -c --statistics -o
es.gmo es.po
dyld: lazy symbol binding failed: Symbol not found: _iconv_open
Referenced from: /Users/ptrajkumar/monobin/lib/libgettextsrc-0.17.dylib
Expected in: flat namespace
dyld: Symbol not found: _iconv_open
Referenced from: /Users/ptrajkumar/monobin/lib/libgettextsrc-0.17.dylib
Expected in: flat namespace
/bin/sh: line 1: 14613 Trace/BPT trap
/Users/ptrajkumar/monobin/bin/msgfmt -c --statistics -o t-${lang}.gmo
${lang}.po
make[4]: *** [es.gmo] Error 133
make[3]: *** [stamp-po] Error 2
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
-
Has anybody else tried building mono under Snow Leopard ? If so, could you
please tell me what I am doing wrong ?
Thanks
Raj
--
View this message in context:
http://old.nabble.com/Need-help-building-Mono-under-Snow-Leopard-tp26632481p26632481.html
Sent from the Mono - Dev mailing list archive at Nabble.com.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch to boehm-gc.c for Android
If GC_no_dls is set to true, GC_find_limit is not called. This causes a seg fault on Android. Patch is attached! (MIT X11, etc). Koush gc.patch Description: gc.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] [PATCH] updates for Android
Hi all, picked up the Android Mono project again since the Soft Debugger was recently released! Here's the patch necessary to make the trunk build for Android. All trivial changes, the rest of the code is the in my androidmono repo on github. Submitted under the MIT X11 license. Koush monosubmission.patch Description: monosubmission.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono 2.4 for ARM
Use: make -DARM_FPU_NONE On 6/30/09 3:39 PM, Jon Shemitz jon.shem...@access-company.com wrote: Many thanks. --with-tls=pthread got me past my first hurdle. Alas, now I get mini-arm.h:28:2: error: #error At least one of ARM_FPU_NONE or ARM_FPU_FPA or ARM_FPU_VFP must be defined. and I can't seem to get past that. I've tried ./configure --disable-mcs-build --with-tls=pthread ARM_FPU_NONE=1 and make ARM_FPU_NONE=1 and ARM_FPU_NONE=1 make and export ARM_FPU_NONE=1 make and I keep getting the same error. What do I have to do to enable software floating point (gnueabi)? From: Zoltan Varga [mailto:var...@gmail.com] Sent: Monday, June 29, 2009 6:36 PM To: Jon Shemitz Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Mono 2.4 for ARM Hi, Try mono 2.4.2, or pass --with-tls=pthread to configure. Zoltan On Tue, Jun 30, 2009 at 1:59 AM, Jon Shemitz jon.shem...@access-company.com wrote: I'm trying to build Mono 2.4 for an ARM device, following the instructions at http://mono-project.com/Mono:ARM and using an existing Scratchbox configuration. I downloaded mono-2.4.tar.bz2 and extracted it with `tar xjf`. The host-mono part went fine, but when I tried to do the Scratchbox part, I had no arm-mono directory. When I tried to ./configure --disable-mcs-build make make install DESTDIR=`pwd`/tmptree in the mono-2.4 directory, `make` gave me a lot of warnings, and finally a series of undefined reference to `GC_local_malloc' errors, culminating in collect2: ld returned 1 exit status make[3]: *** [pedump] Error 1 make[3]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono/metadata' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4/mono' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jon/src/dev/alp/cross/mono-2.4' make: *** [all] Error 2 Are there more up-to-date build instructions somewhere? Is ARM only supported for 1.x? Or am I just too stupid to get Mono running on our platform? ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for io-layer/shared.c that makes it respect the lack of sys/sem.h
Hello again, The Android platform does not implement sys/sem.h, so it needs to fall back to the semaphore-less based implementation that is also available. These changes are to fix compilation errors on the platform. It is probably better to move all the sys/sem.h related code inside a single ifdef for brevity, but this diff provides for a better read/review. Koush shared.c.diff Description: shared.c.diff ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Patch for io-layer/collection.c
Android's build uses the GNU C compiler, but is failing while compiling
gpointer collection_thread (gpointer unused G_GNUC_UNUSED) because it exits
via a pthread_exit, and not via the return statement:
static gpointer collection_thread (gpointer unused G_GNUC_UNUSED)
{
struct timespec sleepytime;
sleepytime.tv_sec = _WAPI_HANDLE_COLLECTION_UPDATE_INTERVAL;
sleepytime.tv_nsec = 0;
while (_wapi_has_shut_down == FALSE) {
nanosleep (sleepytime, NULL);
//_wapi_handle_dump ();
_wapi_handle_update_refs ();
/* This is an abuse of the collection thread, but it's
* better than creating a new thread just for one more
* function.
*/
_wapi_process_reap ();
}
pthread_exit (NULL);
#if !defined(__GNUC__)
/* Even though we tell gcc that this function doesn't return,
* other compilers won't see that.
*/
return(NULL);
#endif
}
I've attached a patch that fixes the Android build by adding another condition
to the #if.
Koush
collection.c.patch
Description: collection.c.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] make --disable-mcs-build fails
I run into this problem too when targeting the ARM platform with -disable-mcs-build: the managed assemblies are built on a speedy x86_64 machine rather than the ARM handheld. I figured it was just some problem with ARM/Android builds that I looked further into. Anyways, your build is actually complete at that point, as docs is the last thing that is built in the list of targets in the Makefile. (I actually usually just remove the docs part from the Makefile altogether to suppress that error) Koush On 5/4/09 9:15 PM, Cambell Prince cambell.pri...@gmail.com wrote: I'm trying to build mono, but without building mcs. This is mainly to support the debian packaging. However, it fails when it tries to build the mono docs as it needs mscorlib.dll. Can I build mono without building the docs as well? Any other thoughts appreciated. ./configure --prefix=/usr/local --disable-mcs-build make EXTERNAL_MCS=false EXTERNAL_RUNTIME=false make[2]: Entering directory `/home/cambell/src/mono-2.4/docs' cd . make -f docs.make topdir=../mcs convert.exe make[3]: Entering directory `/home/cambell/src/mono-2.4/docs' MCS [net_2_0] convert.exe The assembly mscorlib.dll was not found or could not be loaded. It should have been installed in the `/usr/local/lib/mono/2.0/mscorlib.dll' directory. make[3]: *** [convert.exe] Error 1 make[3]: Leaving directory `/home/cambell/src/mono-2.4/docs' make[2]: *** [convert.exe] Error 2 make[2]: Leaving directory `/home/cambell/src/mono-2.4/docs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cambell/src/mono-2.4' make: *** [all] Error 2 TIA Cambell ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Usage of construct properties in a wrapped GObject library
Hi Alberto, you may want to try this out if GAPI does not work out for you: http://www.codeplex.com/clrinterop/Release/ProjectReleases.aspx?ReleaseId=14120 Pinvoke Interop Assistant works much like GAPI: It will parse header files and generate the Pinvokes for you. It's not perfect, but it worked well enough for me when I ran it through OpenGL's gl.h file to import a few hundred methods. (I took care of the errors with some regex replaces and manual tweaking) Koush On 4/26/09 8:38 AM, mardy.tardi ma...@users.sourceforge.net wrote: Hi all, I hope this is the right list for this kind of questions. I have a GObject-based library, written in C, which I want to use from a C# application (f-spot). I generated the bindings with the GAPI tools, but I'm not satisfied with the result. The problem is that the C API for that GObject provides a method that is called my_object_new(), which simply calls g_object_new() with the proper arguments. But the object supports many other construct-only properties, which I want to set from the C# application, and apparently I cannot, because the GAPI tools only generated one constructor which takes no parameters. I guess that by modifying the C library by adding more _new() methods I can get more constructors in the C# API, but is there some other way around it, without modifying the C API? TIA! Alberto -- View this message in context: http://www.nabble.com/Usage-of-construct-properties-in-a-wrapped-GObject-library-tp23243364p23243364.html Sent from the Mono - Dev mailing list archive at Nabble.com. ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] fix for compilation error in socket-io.c for systems that don't support IPv6
Patch is attached. It's just a simple variable typo issue. Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ diff.patch Description: diff.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] fix for compilation error in socket-io.c for systems that don't support IPv6
I just noticed that my previous svn diff had some other changes unrelated to this bug. I've reattached a new diff that contain the changes for only socket-io.c. Sorry for the trouble! Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ From: Koushik K. Dutta Sent: Monday, February 09, 2009 6:16 PM To: 'mono-devel-list@lists.ximian.com' Subject: fix for compilation error in socket-io.c for systems that don't support IPv6 Patch is attached. It's just a simple variable typo issue. Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ diff.patch Description: diff.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] question regarding Mono PInvoke shared library loading behavior
Hi, I had a question regarding how P/Invoke and shared library loading works on Mono. I am trying to run Dalvik (Android's VM) and Mono side by side in the same process. To achieve this, I added some JNI hooks to libmono, and start mono_main from within Dalvik in that fashion. This part is working great. I then have my Mono application also PInvoke into libmono. My assumption was that Mono would use the already loaded libmono, but instead, it seems to be loading a second copy. This is causing issues with my approach, because assumed I could use a couple global variables to set a couple callback pointers, but since two libraries are being loaded, this won't work. Is the loading of a second copy of that shared library expected? (ie, the mono runtime and the managed application intentionally can't load the same native dependencies) Does anyone have any suggestions as to a better way to do this? Perhaps internal calls to proxy calls back into Dalvik? Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to fix build break for Mono on Android
A recent change to mini-arm.c caused a build break in Android. The break is caused by usage of an API call that is not available in the version of gcc that is used by the Android build environment (4.2.1). Android will be upgrading to a newer version of gcc (4.3.1) with their next release. When that happens, I will submit another patch to remove the workaround I have attached. Patch is attached, and submitted under the MIT license. Thanks, Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ androidmono.patch Description: androidmono.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] patch to mono-mman.c to accommodate Android, bug report for Arm thunk handling
Hello again! Android's libc has an implementation of mmap, but does not implement shmem functions. Instead Android uses a different implementation of memory sharing called ashmem. mono-mman.c assumes that if mmap is available/implemented, so is shm_open. This change further reorganizes the code so that mmap and and shm_open are uncoupled (as they are not really dependent on each other). This allows Mono on Android to use mmap instead of malloc. Incidentally, this change came out of necessity: if mmap is not available, Mono falls back to using the malloc based implementation of mono_valloc. The problem with malloc is that it exposed a bug in the Arm thunk handling: If the delta between the of a branch-and-link and the target's instruction pointer is greater than 0x1ff, it will attempt to utilize a thunk to explicitly set the program counter to the target. The problem with this is that the number of entries in the thunk table is hard coded to (code chunk length / 8). So if the intended thunk table fills up due to numerous thunks, it will check the other tables that are available. This is where malloc and mmap seem to behave differently: * mmap seems to provide sequential memory addresses with every successive call to the function. This works out well, since then the original branch-and-link that is being modified is in branch range of thunk tables that were created for other code chunks. * malloc , at least on Android, seems to provide wildly different addresses with each successive call (in a deterministic manner it seems). In my case, it starts out providing addresses in the 0x0070 range. Then the addresses jump up into the 0x4000 range. This is where if a thunk table fills up, and Mono can't find a suitable thunk slot (one that is in branch range), it fails at the assert in mini-arm.c:handle_thunk:~2035. So, although this bug exists for any Arm build, this patch just keeps it from surfacing on Android (for now). I looked into actually fixing this properly, because it is possible that it could occur with mmap (it is just very unlikely). But from my investigation, the changes would be too deep (changes to arm_patch, and more). And I'm not familiar enough with the code... yet. :) Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ androidmono.patch Description: androidmono.patch ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Question regarding compiler optimizations causing floating point failure on Arm
Hi, I am building Mono/Arm under the Android build environment. The Android
build environment uses various gcc architecture and optimizations flags which I
detail at the bottom of this mail.
If I use the default flags of their build system, the following C# program has
some very interesting/buggy results with regard to floating point values!
public static class Program
{
public static int Main(string[] args)
{
float num = 1.0f;
Console.WriteLine(num); // this prints 2.561887???!
return 0;
}
}
But if in my Android.mk (Android build's makefile), I use the -O0 flag (turn
off all optimizations), the program displays 1 as expected.
Does anyone have any thoughts/ideas as to why this is happening?
I have tried using ARM_FPU_VFP, ARM_FPU_NONE, and ARM_FPU_FPA.
Default Android Release Flags:
my @compile_args = (
-march=armv5te,
-mtune=xscale,
-msoft-float,
-mthumb-interwork,
-fpic,
-fno-exceptions,
-ffunction-sections,
-funwind-tables, # static exception-like tables
-fstack-protector, # check guard variable before return
-fmessage-length=0); # No line length limit to error messages
my @optimize_args = (
-O2,
-finline-functions,
-finline-limit=300,
-fno-inline-functions-called-once,
-fgcse-after-reload,
-frerun-cse-after-loop, # Implicit in -O2 per texinfo
-frename-registers,
-fomit-frame-pointer,
-fstrict-aliasing, # Implicit in -O2 per texinfo
-funswitch-loops);
Koushik Dutta
www.koushikdutta.comhttp://www.koushikdutta.com/
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment
Hi again all, I have gotten Mono cross compiling within the Android build environment successfully. The good part about this is that it is now properly using Android's linker and libc (Bionic); ie, I am no longer using glibc or ld-linux.so.3. So that reduced the memory footprint, increased the speed (Bionic uses Thumb code), and also allows interop with Android's shared libraries (which didn't work before due to a different linker script being used that caused incompatibility). I've attached a patch of what is needed to change in Mono code to get this working. Brief summary: 1. gcconfig.h: Android's Mono is not using glibc anymore, so the GC needs to search for the data start segment when PLATFORM_ANDROID is defined. 2. io.c: Although Android has statfs, there are some missing functions and defines that prevent GetDiskSpaceFreeEx from compiling. I used the PLATFORM_ANDROID define again to make it fall back to the simpler implementation. 3. attach.c: The HAVE_GETPWUID_R define should be checked and the proper function used (getpwuid in Android's case). 4. socket-io.c: Android has an incomplete ipv6 implementation, so I needed to undef AF_INET6 to prevent compilation errors. 5. mini-arm.c: Android's toolchain does not implement __clear_cache, so I needed to implement it properly for Mono to function. I have opened a bug on the Android team about this problem: http://code.google.com/p/android/issues/detail?id=1803. However, they tend to be fairly unresponsive... 6. mono-mmap.c: The HAVE_SHM_OPEN define should be checked as well. Creating a build for Android does not use the usual configure/make process anymore. Instead, Mono must be an external project under your local Android source tree, and cross compiled in that environment. To view the rest of the changes (mostly tweaks and filling holes in libc) and build instructions, you can go to http://code.google.com/p/androidmono/. I'm contributing the both the internal and external changes to Mono under the MIT/X11 license. (Please disregard my previous patch, as this change supersedes that) Thanks, Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ From: Rodrigo Kumpera [mailto:kump...@gmail.com] Sent: Wednesday, January 14, 2009 4:18 AM To: Koushik K. Dutta Subject: Re: [Mono-dev] Tweaks needed in security.c for running Mono on Android - patch included I loved the idea of bringing mono to Android, so keep everyone posted about your changes. We'll make sure they are integrated back into the main tree once you figure out the way to go. On Tue, Jan 13, 2009 at 11:53 PM, Koushik K. Dutta ko...@koushikdutta.commailto:ko...@koushikdutta.com wrote: Hi Rodrigo. Thanks for your response. After working on Mono/Android a bit further, I decided I need to think through the problem more. Linux and Android use significantly different linkers which is causing other various issues. I may end having to link versus Bionic after all, and implementing whatever dependencies are missing. So for now, this change may be unnecessary... Koushik Dutta www.koushikdutta.comhttp://www.koushikdutta.com/ From: Rodrigo Kumpera [mailto:kump...@gmail.commailto:kump...@gmail.com] Sent: Monday, January 12, 2009 10:24 AM To: Koushik K. Dutta Cc: mono-devel-list@lists.ximian.commailto:mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tweaks needed in security.c for running Mono on Android - patch included Hi Koushik, To have your patch accepted into the mono runtime you need to state that your contribution is under the MIT/X11 license otherwise we can't commit it. Besides this, most of the code in System.Security is windows centered and makes no sense under Android. Maybe the best solution is just remove it as using it would make no sense at all. Thanks, Rodrigo 2009/1/11 Koushik K. Dutta ko...@koushikdutta.commailto:ko...@koushikdutta.com Hi all, I'm working on getting Mono running under Android. So far, I've been able to get things running with next to no code changes (by way of configure, compiler and linker options). I did run into one issue though that required a code change. Mono has a dependency on libc.so. On Android, Google implemented a custom lightweight version of libc.so, which they call Bionic. I have tried building Mono against Bionic, but at the moment, it seems basically impossible because Bionic does not have Unicode support. (I will dig into other solutions for this further, but it's low priority at the moment... I want to get things running :)) So, as a result, Mono on Android needs to be packaged with the standard ARM/Linux version of libc. However, there are significant differences between the Linux file system and Android file system. So when Mono's uses libc's getpwuid and getpwuid_r, it fails, and causes further problems in the runtime. Linux's getpwuid works by examining various files in /etc. But, Android does not have a /etc. Android
Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment
Hi Christian, the failure is occurring at the code seen below in GetDiskSpaceFreeEx: #ifdef HAVE_STATVFS ret = statvfs (utf8_path_name, fsstat); isreadonly = ((fsstat.f_flag ST_RDONLY) == ST_RDONLY); #elif defined(HAVE_STATFS) ret = statfs (utf8_path_name, fsstat); isreadonly = ((fsstat.f_flags MNT_RDONLY) == MNT_RDONLY); #endif Bionic does not have the statvfs function, and its statfs struct does not have the f_flags member. It also does not have the the MNT_RDONLY macro/define. Although I can add the macro, nothing can be done about the missing/different structures. So that hole in Bionic is not really patchable unfortunately. However, the fallback implementation of GetDiskSpaceFreeEx works fine... so it's not too huge a deal. My change is forcing it to use the fallback. Koushik Dutta www.koushikdutta.com -Original Message- From: Christian Prochnow [mailto:cpr...@seculogix.de] Sent: Sunday, January 18, 2009 2:11 AM To: Koushik K. Dutta Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment Hi, Koushik K. Dutta schrieb: 2. io.c: Although Android has statfs, there are some missing functions and defines that prevent GetDiskSpaceFreeEx from compiling. I used the PLATFORM_ANDROID define again to make it fall back to the simpler implementation. could you give me the exact compilation error, maybe i can tweak the GetDiskFreeSpaceEx implementation to also compile on the Android platform. Best regards, Christian -- Christian Prochnow Geschäftsführer SecuLogiX Systems GmbH Mohriner Allee 28 12347 Berlin http://www.seculogix.de mobile: +49 (0)177 313 02 57 fon: +49 (0)700 SECULOGIX Geschäftsführer: Christian Prochnow Handelsregister: B 96491, Amtsgericht Charlottenburg ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment
Thanks! However, it looks like your commits missed the change that I made in mono/metadata/attach.c. Koushik Dutta www.koushikdutta.com -Original Message- From: Zoltan Varga [mailto:var...@gmail.com] Sent: Sunday, January 18, 2009 6:51 AM To: Koushik K. Dutta Cc: Christian Prochnow; mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment Hi, Your patch is now in SVN. Thanks! Zoltan On Sun, Jan 18, 2009 at 11:50 AM, Koushik K. Dutta ko...@koushikdutta.com wrote: Hi Christian, the failure is occurring at the code seen below in GetDiskSpaceFreeEx: #ifdef HAVE_STATVFS ret = statvfs (utf8_path_name, fsstat); isreadonly = ((fsstat.f_flag ST_RDONLY) == ST_RDONLY); #elif defined(HAVE_STATFS) ret = statfs (utf8_path_name, fsstat); isreadonly = ((fsstat.f_flags MNT_RDONLY) == MNT_RDONLY); #endif Bionic does not have the statvfs function, and its statfs struct does not have the f_flags member. It also does not have the the MNT_RDONLY macro/define. Although I can add the macro, nothing can be done about the missing/different structures. So that hole in Bionic is not really patchable unfortunately. However, the fallback implementation of GetDiskSpaceFreeEx works fine... so it's not too huge a deal. My change is forcing it to use the fallback. Koushik Dutta www.koushikdutta.com -Original Message- From: Christian Prochnow [mailto:cpr...@seculogix.de] Sent: Sunday, January 18, 2009 2:11 AM To: Koushik K. Dutta Cc: mono-devel-list@lists.ximian.com Subject: Re: [Mono-dev] Tweaks needed to get Mono compiling in the Android build environment Hi, Koushik K. Dutta schrieb: 2. io.c: Although Android has statfs, there are some missing functions and defines that prevent GetDiskSpaceFreeEx from compiling. I used the PLATFORM_ANDROID define again to make it fall back to the simpler implementation. could you give me the exact compilation error, maybe i can tweak the GetDiskFreeSpaceEx implementation to also compile on the Android platform. Best regards, Christian -- Christian Prochnow Geschäftsführer SecuLogiX Systems GmbH Mohriner Allee 28 12347 Berlin http://www.seculogix.de mobile: +49 (0)177 313 02 57 fon: +49 (0)700 SECULOGIX Geschäftsführer: Christian Prochnow Handelsregister: B 96491, Amtsgericht Charlottenburg ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-dev] Tweaks needed in security.c for running Mono on Android - patch included
Hi all, I'm working on getting Mono running under Android. So far, I've been
able to get things running with next to no code changes (by way of configure,
compiler and linker options).
I did run into one issue though that required a code change. Mono has a
dependency on libc.so. On Android, Google implemented a custom lightweight
version of libc.so, which they call Bionic. I have tried building Mono
against Bionic, but at the moment, it seems basically impossible because Bionic
does not have Unicode support. (I will dig into other solutions for this
further, but it's low priority at the moment... I want to get things running :))
So, as a result, Mono on Android needs to be packaged with the standard
ARM/Linux version of libc. However, there are significant differences between
the Linux file system and Android file system. So when Mono's uses libc's
getpwuid and getpwuid_r, it fails, and causes further problems in the runtime.
Linux's getpwuid works by examining various files in /etc. But, Android does
not have a /etc. Android has a uid/gid repository that is very different from
typical Linux distributions.
For reference, here is Bionic's implementation of getpwuid (there is no
getpwuid_r):
struct passwd* getpwuid(uid_t uid)
{
stubs_state_t* state = __stubs_state();
struct passwd* pw;
if (state == NULL)
return NULL;
pw = state-passwd;
if ( android_id_to_passwd(pw, uid) != NULL )
return pw;
if (uid AID_APP) {
errno = ENOENT;
return NULL;
}
snprintf( state-app_name_buffer, sizeof state-app_name_buffer,
app_%d, uid - AID_APP );
pw-pw_name = state-app_name_buffer;
pw-pw_dir = /data;
pw-pw_shell = /system/bin/sh;
pw-pw_uid = uid;
pw-pw_gid = uid;
return pw;
}
getpwuid is used in three locations Mono. The two troublesome ones are in
mono/metadata/security.c in the functions GetTokenName and IsMemberOf. (The
third is in pwd.c for Mono's Posix syscall wrapper, but that is not causing the
problem. I'll fix that later.)
I have attached a patch file that I have successfully built and tested against
Android. It is also regression safe, as all the new code is inside a #ifdef
PLATFORM_ANDROID block. The workaround is simple, and there are comments
explaining how the Android uid model works.
Alternatively, I can obviously compile a custom version of libc.so for Mono,
but I do not think that is a good solution. Mono is already using #ifdef
PLATFORM_WIN32 at the same points in code that I placed my PLATFORM_ANDROID,
and I'm assuming that the Mono developers will be more open to my proposed
changes.
For information about how to build Mono to target Android, you can reference my
post: http://www.koushikdutta.com/2009/01/building-mono-for-android.html. Or
feel free to contact me.
Thanks,
Koushik Dutta
www.koushikdutta.comhttp://www.koushikdutta.com/
Koushik Dutta
www.koushikdutta.comhttp://www.koushikdutta.com/
security.c.patch
Description: security.c.patch
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
