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

Re: [MirageOS-devel] [mirage-platform] Switched to dietlibc's generic libm (4abf42d)

On 7 May 2014 22:46, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
> On 7 May 2014, at 15:12, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> On 7 May 2014 14:54, Anil Madhavapeddy wrote:
>> Picking a "better libc and libm" is something we should figure out on the
>> list. There are a few new contenders since the initial import of dietlibc...
> That would be good. I've been hacking around trying to get a feel for what
> needs to be done first.
> Replacing dietlibc is first on my list of things that need doing (even if
> only replacing it with the latest version). I'm guessing the current version
> was imported from a modified CVS snapshot (and doesn't include ARM support).
> So my plan was to do a clean import of 0.33 and try to get Mirage working on
> x86_64 with that first.
> Yes, it came from a CVS snapshot after finding a ton of bugs in the last
> released version then.  The libm came from OpenBSD.
> Then the Xen headers should be updated to include ARM support. It would be
> good to do a clean import first and then apply the Mirage modifications as a
> separate commit, to make future updates easier.
> Yep.
> libm needs replacing with something that supports ARM. The compiler seemed
> to be generating function calls for exp, log, etc, rather than using the
> chip's floating point instructions, so that will need looking at.
> Would this be to do with the VFPE choice (not finding vfpe3)?  Not a huge
> concern in the short term as we don't depend on fast FP anyway.
> However, work has come to a standstill here as my new laptop has arrived...
> By the way, what's the best way to install mirage-platform from a local Git
> checkout so that opam can see it?
> Just confirming what Mort said:
> $ git clone <repo>
> $ opam pin mirage-xen <repo>
> Then "opam update -u" will rebuild from your local repo.

Note: it looks like opam is replacing symlinks with their targets.
This prevents v1.1.1 from building on my machine, because the ocaml
symlink is replaced by a directory, which confuses the build:

===== ERROR while installing mirage-xen.pinned =====
# opam-version 1.1.1
# os           linux
# command      make xen-build
# path         /home/tal/.opam/4.01.0/build/mirage-xen.pinned
# compiler     4.01.0
# exit-code    2
# env-file     
# stdout-file  
# stderr-file  
### stdout ###
# ...[truncated]
#                               - Building runtime/libocaml.mll
#                       - Building runtime/libocaml.mlpack
#               - Building runtime/libocaml.mllib
#               - Building runtime/libocaml.clib
#               - Building runtime/libocaml.cclib
# Makefile:17: recipe for target 'build' failed
# make[2]: Leaving directory
# Makefile:16: recipe for target 'build' failed
# make[1]: Leaving directory '/home/tal/.opam/4.01.0/build/mirage-xen.pinned'
# Makefile:37: recipe for target 'xen-build' failed
### stderr ###
# make[2]: *** [build] Error 6
# make[1]: *** [build] Error 2
# make: *** [xen-build] Error 2

This makes it build:

$ cd ~/.opam/4.01.0/build/mirage-xen.pinned
$ ls -ld xen/runtime/ocaml
drwxr-xr-x 2 tal tal 4096 May  8 15:31 xen/runtime/ocaml
$ rm -rf xen/runtime/ocaml
$ ln -s ocaml.4.01.0 xen/runtime/ocaml
$ make xen-build
$ make xen-install

opam still doesn't think it's installed, though.

(work-around: disable the build target in xen/Makefile and let opam
just install your already-built version)

There's a similar problem trying to use it with mini-os, which
contains a symlink "mini-os -> ." which it can't expand.

Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.