Antti Kantee writes ("Re: minor app-tools modifications"):
> On 22/07/14 15:31, Ian Jackson wrote:
> > Can we have some compatibility wrappers ? Otherwise osstest's tests
> > are going to fail. Alternatively I could make osstest understand both
> > but I think that's probably more work.
> >
> > We can delete the compatibility wrappers after I have updated osstest
> > to use the new ones.
>
> I will add compat wrappers.
Right.
> > Not without coordinating with code in xen.git. Defining both would be
> > fine IMO.
>
> I'm trying to get rid of the whole "rumpuser-xen" name, because as
> already earlier stated, it refers to the rump kernel hypercall
> implementation, and the whole repo is way beyond that stage now.
Does that mea the repo is going to change names too ?
> I assume xen.git knows it's building Xen stuff, and is only interested
> in if it's building for the rumpapp stack or not. Can we agree to
> define both for now, and phase __RUMPUSER_XEN__ out later? That way, I
> can use the same wrapper on any potential non-Xen platforms.
Sure, defining both now and phasing __RUMPUSER_XEN__ out is the right
approach.
> >> -exec "$prog" --host=!ARCH!-rumpxen-netbsd CC=!APPTOOLS!/rumpapp-xen-cc
> >> +CC=!APPTOOLS!/rumpapp-xen-cc exec "$prog" --host=!ARCH!-rumpxen-netbsd
> >
> > Um, what is the difference here ? I can't remember why I passed it as
> > an argument but I think I found setting it in the environment wasn't
> > effective. (But perhaps that was in the context of make.)
>
> The difference is it working or not. thttpd with the old configure wrapper:
>
> === snip ===
> loading cache ./config.cache
> checking host system type... Invalid configuration
> `amd64-rumpxen-netbsd': machine `amd64-rumpxen' not recognized
Blimey. Is thttpd's configure autoconf-generated ? I don't
understand why thttpd is doing this when xen.git's configure isn't.
> >> However, that makes running configure very slow, since the whole xen
> >> image is linked for every test.
> >
> > Is it not currently ? Surely it's not using the base compiler and
> > linker. That wouldn't work at all.
>
> Apparently configure scripts are. I'm guessing the probe results
> between NetBSD and host are similar enough for config.h to end up with
> correct enough definitions for things to work in the small subset of
> things that we're tried.
>
> The build itself is using the stunt-linker.
Well in any case I think we do need to do the complete link in each
test. Perhaps there is a way to make it faster.
> > This is GNU terminology. It's very confusing. They use "host" to
> > refer to what everyone else calls "target". They use "target" only
> > for the final target architecture cross toolchain (eg, a Canadian
> > cross where there are three different architectures).
>
> Ok. The canadian thing always makes my head spin, and apparently they
> even changed the implications of the three parameters recently, so it
> was easier to outsource the head scratching ;)
Yes. Importing their canadian cross terminology (rather confusing
even then) into the whole non-toolchain world was a bad mistake but
now we're all stuck with it.
Thanks,
Ian.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
