mono

[pepedog]

Been messing (probably wasting my time) with mono.
According to http://www.mono-project.com/Mono:ARM you build half on a cross compiler, and half on the device.
Done on trimslice, package is 2 Mb, it should be 28Mb, mono --help runs fine, but anything else needs dll's created on cross compiler.
Don't have a cross compiler, so here's what works so far. Tell me to shut up if this is a waste of time.
$this->bbcode_second_pass_code('', 'CARCH="armv7h"
CHOST="armv7l-unknown-linux-gnueabi"
CFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -DARM_FPU_FPA -O2 -pipe"
CXXFLAGS="-march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -DARM_FPU_FPA -O2 -pipe"
./configure --prefix=/usr --sysconfdir=/etc --with-libgdiplus=installed CC="distcc" --disable-mcs-build')

[kmihelich]

That's about to the point that I get to building it here. What is stopping it from building out complete is gmcs. Disclaimer: I haven't really dived into the compile steps, so I don't entirely know what I'm talking about with with mono. On v5, mono is able to compile its own gmcs.exe, or is finding one to use to bootstrap properly. v7 isn't able to get past this part. v5 had this same issue when mono released 2.10, but it was resolved at 2.10.2.

What I've been thinking is to use the v5 gmcs to bootstrap v7 hard. Essentially creating my own monolite using those binaries, since they are all static linked. I just haven't freed up the time to do this yet.
$this->bbcode_second_pass_code('', '# ldd /usr/bin/gmcs
not a dynamic executable')

Mono is a lot like Java in that it needs some prior version of itself to fully build itself.

[kmihelich]

Using the v5 as a launching point was a failure. But since mono needs at least 2.4 to build itself, I'm going to try building 2.8 (which was a known very-good on v5) and see if I can get that to build. If that goes, I should be able to use that to bring up 2.10. That's the theory right now anyway.

Everything I find in the docs essentially says that mono is capable of bootstrapping itself; it builds piece by piece, using the each step to help the next. This works fine on v5.. 2.10.2 built out of the box without a whimper. Not sure what the mess is with v7 now.

[pepedog]

It seems to me that when mono builds something (itself) it ignores flags. Or it doesn't know about 2 types of hard.

[kmihelich]

From what I've been able to deduce, it doesn't like something about about the programs it builds or the locations it finds them in. Tarball releases are able to fully bootstrap themselves, git/svn checkouts or daily snapshots are the ones that require monolite or the existing install to behave.

I've managed to build the core mono applications (not the C# components) on v7 by adjusting the PKGBUILD to pull out the C# stuff, and configuring with --disable-mcs-build. Also adjusted CFLAGS to be just -O from -O2, and added -DARM_FPU_VFP=1. Scrounging the depths of the Google I found some references to dual-core ARM having issues with higher optimization levels, and unless you define ARM_FPU_VFP it tries to do things soft-float.

I have a build running right now on the full unadulterated PKGBUILD for mono.. having the binaries in the system should help things. If it's a success, there shouldn't be any issues about this in the future. And, naturally, it will be in the repo tomorrow.

I'm going to be slowing the pace on the v7 build-out for a few days or so while I work on getting the build system ready to go for supporting a European mirror. Pretty soon you'll have access to a very fast repo right across the channel, pepedog. The changes will also eliminate packages duplicated in repos when Arch changes them, deleted packages, and lots of general housekeeping stuff that is a manual operation at this point.