Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:
> Ferenc Wagner, le Tue 28 Apr 2009 22:46:19 +0200, a écrit :
>> Samuel Thibault <samuel.thibault@xxxxxxxxxxxx> writes:
>>> Ferenc Wagner, le Tue 28 Apr 2009 21:56:07 +0200, a écrit :
>>>
>>>> But then trying the operation itself provides the exact same
>>>> diagnostics. This is what I mean by "pointless".
>>>
>>> Ok, but applications could still be upset to see access() work and not
>>> open(), or vice-versa.
>>
>> Sure, but then they are buggy.
>
> So be they. We unfortunately can't change all of them just by will.
I tried to imply there shouldn't be that many of them. Maybe none...
Well, at least not too many which could be usefully run in a stubdom.
>>>> #if defined(HAVE_POSIX_MEMALIGN)
>>>> if (posix_memalign (&p, align, size) != 0)
>>>> p = 0;
>>>> #elif defined(HAVE_MEMALIGN)
>>>> p = memalign (align, size);
>>>
>>> Errr, so grub2 doesn't unconditionally use posix_memalign. How did
>>> grub2 detect HAVE_POSIX_MEMALIGN?
>>
>> By autoconf:
>> AC_CHECK_FUNCS(posix_memalign memalign asprintf)
>
> Mmmmm, and I guess it's linking against the host OS, not the stubdom OS,
> grmbl.
Ugh, that can be. One can't pass LDFLAGS to configure, as then:
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
Cross compilation should be made more explicit somehow.
>>> Oh right, sorry. The final link is not done there but by the minios
>>> paragraph of stubdom/Makefile. You can either set APP_LDLIBS to
>>> -lncurses there, to override the empty default of mini-os/Makefile, or
>>> add -lncurses to APP_LDLIBS in the ifeq($libc),y) section along others.
>>
>> This is what I did in the POC.
>
> Err, in your patch it wasn't in the ifeq section but the empty
> declaration.
Yes, I read the above as allowing that. But I'll move it.
--
Thanks,
Feri.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home