From owner-svn-src-all@FreeBSD.ORG Sun Dec 29 17:16:35 2013 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8F0A55F7; Sun, 29 Dec 2013 17:16:35 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5E1C11333; Sun, 29 Dec 2013 17:16:35 +0000 (UTC) Received: from [192.168.2.84] (50-0-150-213.dsl.static.sonic.net [50.0.150.213]) (authenticated bits=0) by mail.xcllnt.net (8.14.7/8.14.7) with ESMTP id rBTHGWYE012847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 29 Dec 2013 09:16:33 -0800 (PST) (envelope-from marcel@xcllnt.net) Content-Type: multipart/signed; boundary="Apple-Mail=_5D11B954-878F-403B-9B49-184339F30D08"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r260022 - head/lib/libkvm From: Marcel Moolenaar In-Reply-To: <20131229090338.GV59496@kib.kiev.ua> Date: Sun, 29 Dec 2013 09:17:00 -0800 Message-Id: <4A5D5324-6F51-4328-BC52-851F5BB4B33D@xcllnt.net> References: <201312282301.rBSN1wWP002326@svn.freebsd.org> <28D86FF3-F13C-4EB1-AEED-4051F2944E27@xcllnt.net> <20131229090338.GV59496@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1827) Cc: "svn-src-head@freebsd.org" , svn-src-all , Marcel Moolenaar , "src-committers@freebsd.org" , Peter Wemm X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 17:16:35 -0000 --Apple-Mail=_5D11B954-878F-403B-9B49-184339F30D08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Dec 29, 2013, at 1:03 AM, Konstantin Belousov = wrote: > On Sat, Dec 28, 2013 at 06:39:07PM -0800, Marcel Moolenaar wrote: >>=20 >> On Dec 28, 2013, at 4:40 PM, Peter Wemm wrote: >>=20 >>> On Sat, Dec 28, 2013 at 4:04 PM, Peter Wemm wrote: >>>> On Sat, Dec 28, 2013 at 3:01 PM, Marcel Moolenaar = wrote: >>>>> Author: marcel >>>>> Date: Sat Dec 28 23:01:57 2013 >>>>> New Revision: 260022 >>>>> URL: http://svnweb.freebsd.org/changeset/base/260022 >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Note that this commit does not change any of the = architecture-specific >>>>> code for cross-compilation. >>>>=20 >>>> 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. >>>>=20 >>>> I'm really sorry, I accidentally blew away the failure log. I'll = have >>>> another in a few minutes. >>>=20 >>>=20 >>> This is from stage5.1, the lib32 build: >>>=20 >>> /usr/src/lib/libkvm/kvm_amd64.c:78:2: error: unknown type name = 'pml4_entry_t' >>> pml4_entry_t *PML4; >>> ^ >>=20 >> Ugh. I'll probably revert... >=20 > 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. --=20 Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_5D11B954-878F-403B-9B49-184339F30D08 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlLAWQwACgkQpgWlLWHuifYpWQCfczY+FVK++35YPDSRLGqbyatZ OUIAnieVysPV7dOy7i810j6bYzfpUO7v =mtWG -----END PGP SIGNATURE----- --Apple-Mail=_5D11B954-878F-403B-9B49-184339F30D08--