svn commit: r260022 - head/lib/libkvm

[Marcel Moolenaar]

On Dec 29, 2013, at 1:03 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:

> On Sat, Dec 28, 2013 at 06:39:07PM -0800, Marcel Moolenaar wrote:
>> 
>> On Dec 28, 2013, at 4:40 PM, Peter Wemm <peter at wemm.org> wrote:
>> 
>>> On Sat, Dec 28, 2013 at 4:04 PM, Peter Wemm <peter at wemm.org> wrote:
>>>> On Sat, Dec 28, 2013 at 3:01 PM, Marcel Moolenaar <marcel at freebsd.org> wrote:
>>>>> Author: marcel
>>>>> Date: Sat Dec 28 23:01:57 2013
>>>>> New Revision: 260022
>>>>> URL: http://svnweb.freebsd.org/changeset/base/260022
>>>>> 
>>>>> Log:
>>>>> Allow building a cross libkvm by setting TARGET_ARCH. The library so
>>>>> produced will be called libkvm-${ARCH} instead of libkvm. This allows
>>>>> installing it alongside the native version.
>>>>> For symbol lookups, use ps_pglobal_lookup() instead of __fdnlist()
>>>>> when building a cross libkvm. It is assumed that the cross tool that
>>>>> uses the cross libkvm also provides an implementation for this
>>>>> proc_services function.
>>>>> 
>>>>> Note that this commit does not change any of the architecture-specific
>>>>> code for cross-compilation.
>>>> 
>>>> Are you sure about this? I just got a brand new buildworld failure on
>>>> an amd64 machine.  The lib32 build code was trying to use 64 bit pmap
>>>> definitions and failed miserably.
>>>> 
>>>> I'm really sorry, I accidentally blew away the failure log.  I'll have
>>>> another in a few minutes.
>>> 
>>> 
>>> This is from stage5.1, the lib32 build:
>>> 
>>> /usr/src/lib/libkvm/kvm_amd64.c:78:2: error: unknown type name 'pml4_entry_t'
>>>       pml4_entry_t    *PML4;
>>>       ^
>> 
>> Ugh. I'll probably revert...
> 
> Might be, it makes more sense to disable libkvm compat32 build ?

Possibly. I would not do it because of the changes I made. While
we don't have a lot of libraries with cross-utility, I also don't
think libkvm is the only one. So, it's better to fix the Makefile
and keep it included in build32 as it's sets an example.

Independently of the above: if we agree that the use case of
building 32-bit libs changed over the years from providing 32-bit
compat to apps that can't be recompiled to providing an ILP32
runtime environment on a 64-bit host and that we have ports for
the compat case, then we can indeed ask the question whether or
not to build libkvm. I think it's perfectly fair to declare
certain libs or utilities as inherently "native" and as such not
provide 32-bit variants for them.

That said: cross-development has different requirements and for
libkvm it can be seen that the need for a non-native variant is
tied to the need for a non-native kgdb (for example). And as a
developer, I do like our tools to be inherently "cross". This
would argue for keeping libkvm in build32 for the purpose of
building a cross-libkvm.

-- 
Marcel Moolenaar
marcel at xcllnt.net


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20131229/a0aaef83/attachment.sig>