On Dec 29, 2013, at 1:03 AM, Konstantin Belousov <kostik...@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 <pe...@wemm.org> wrote: >> >>> On Sat, Dec 28, 2013 at 4:04 PM, Peter Wemm <pe...@wemm.org> wrote: >>>> On Sat, Dec 28, 2013 at 3:01 PM, Marcel Moolenaar <mar...@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 mar...@xcllnt.net
signature.asc
Description: Message signed with OpenPGP using GPGMail
