Antti Kantee writes ("Re: [PATCH] app-tools: Support old -D__RUMPUSER_XEN__ for
now"):
> On 05/02/15 11:03, Ian Jackson wrote:
> > Without this disablement of dynamic linking, the current code fails to
> > build.
>
> Well that's a good reason. I though there were dl*() stubs, but maybe I
> thought wrong. How do I build the current code? The set of commands is
> probably somewhere in the osstest logs, but it wasn't immediately
> obvious to me where exactly.
The exact set of runes are in these logfile, for example:
http://www.chiark.greenend.org.uk/~xensrcts/logs/33866/build-amd64-rumpuserxen/5.ts-rumpuserxen-build.log
http://www.chiark.greenend.org.uk/~xensrcts/logs/33866/build-amd64-rumpuserxen/6.ts-xen-build.log
But, to summarise:
[ build Xen tools for the host ]
git clone https://github.com/rumpkernel/rumprun-xen rumpuserxen
[ git operations to make sure we are using the intended version,
sort out submodules, etc. ]
cd rumpuserxen
export
XEN_HEADERS=/home/osstest/build.33866.build-amd64-rumpuserxen/xendist/usr/local/include/xen
./buildxen.sh
[ copy some of the build products into deliverables area
for use in tests ]
cd ..
git clone [xen.git] xen
[ git operations to ensure right version etc. ]
cd xen
echo >>.config debug=y
[ various other config stuff which is probably not relevant ]
[...]/rumpuserxen/app-tools/rumpxen-app-configure \
./configure --sysconfdir=/etc
[...]/rumpuserxen/app-tools/rumpxen-app-make make -j4 tools
[ copy remaining build products into deliverables area ]
> > That would certainly be nice but it was more than I was prepared to
> > bite off at the time.
>
> Oh I wasn't suggesting you should do it, just that one day "dynamic"
> linking support might be available.
Yes.
Dynamic linking support isn't really needed or useful in libxc in a
rump kernel environment, so disabling it isn't wrong. If and when
rumprun gets dl* support we can, eventually, remove this special case.
It would perhaps be nicer if configure could spot the absence of
dynamic linking support but given that we need to switch out the
implementation of the underlying hypercalls etc. too, turning off
dynamic linking hardly seems a bridge too far.
Xen generally, and libxc more specifically, is unusual compared to
other things one might build for rumprun-xen: it needs to reach under
the covers, and know that special stuff is going on. So, while having
special patches for (say) gettext or glib would be annoying and ought
to be unnecessary, having special code in xen.git is almost
inevitable.
Thanks,
Ian.
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
