From owner-freebsd-ports@freebsd.org Fri Dec 8 11:46:15 2017 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 497D1E8110B; Fri, 8 Dec 2017 11:46:15 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA2B96F08E; Fri, 8 Dec 2017 11:46:14 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id y82so4234272wmg.1; Fri, 08 Dec 2017 03:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:reply-to:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=89eJbFrl6iufM30k2sQ+5DUQz0CzPbQ9zOjHymQnFAs=; b=rGdQW2rMA8jWSRauGS8FIPTp22N794CCEytYL0uOvOF6QxXTKqnbRtK45kP3enZb3f jpsfvdkBllsDfZRCCOQTCIOe7GGixYa7KFba7O/5r4OwnadBpIG7J+OwmraJbF+iLqYx UOvNobfmpIwwxKZyTuIJcuwbe2IK7T2Bihy4GkSyAc/dtud62Y76E9UHwXFOMkFdhihX EB389v3MCPWU0LZy1Zc1FMhDAWh77qt5/thCgMaNHs/zkn6XpzuVzPDmAhpYsreAIjUw UAOYw1oY/WM/bGQYiOK/K8G2svGMN9EHGGp0RVQYKRrrkbgMUG0tS+rUkOpFPsHzpTzP PaSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=89eJbFrl6iufM30k2sQ+5DUQz0CzPbQ9zOjHymQnFAs=; b=NlJ3vrbRIlikcWNAPTapgKIaYi6XBNvcRV2oticXBKQ6qJQt1e91WccwAwvJkwS0R5 SQxoCW94pCykkCMDcgO3BYFLuS6KXRaRTunPNJLDPq2wzdybxMclCBK7qZMu0rbL+qEJ DLNYmHO24/yX9hF//lDH3N9UomsJ9jgKznXzeUX9qUswkaYk7Z5uoFpA1OvlOnla+rtT CJv40WBE0NM7qrKWmzlMvYSSWU6+/MJTv0J18oP192l6xMJga/RXBDYwVBmUAvXxTK2P EJ9hESR/T+phexpViAmWs2hBuc1PBIUsJAS+UUSJH7eMcOyyIC9eLnaBUICMPrXKcwcn BWJA== X-Gm-Message-State: AKGB3mJFeR25sGJnMqQcUlQ4ToXahXiJfVco/cDPT/6IwDUbdSm7y+7Q JDcvlq3MJMTGCKmM1+RkllISFbQX59g= X-Google-Smtp-Source: AGs4zMYIX8squjxruku1rtTYqbPxogIkFCHQbc9Uj1oaD1c9tGGHV4YdW7Yf7+XkB7dsnvya+7KmRg== X-Received: by 10.28.35.4 with SMTP id j4mr3549284wmj.55.1512733572378; Fri, 08 Dec 2017 03:46:12 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id 128sm1444260wmi.28.2017.12.08.03.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Dec 2017 03:46:11 -0800 (PST) From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: For armv7 (cross build target): multimedia/libvpx depends on the GNU C library function getauxval and so fails to build; so, disable its expectation? To: Ian Lepore , Jan Beich , Mark Millard Cc: Freebsd-arm , FreeBSD Ports References: <1512583709.58601.49.camel@freebsd.org> Message-ID: <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> Date: Fri, 8 Dec 2017 12:46:12 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1512583709.58601.49.camel@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Dec 2017 11:46:15 -0000 On 06.12.2017 19:08, Ian Lepore wrote: > On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote: >> Mark Millard writes: >> >>> >>> For armv7 attempting to build multimedia/libvpx >>> (via an indirect dependency) leads to: >>> >>> cp libvpx_g.a libvpx.a >>> vpx_ports/arm_cpudetect.c.o: In function `arm_cpu_caps': >>> /wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1/vpx_ports/arm_cpudetect.c:198: undefined reference to `getauxval' >>> c++: error: linker command failed with exit code 1 (use -v to see invocation) >>> gmake[2]: *** [Makefile:384: libvpx.so.4.1.0] Error 1 >>> gmake[1]: *** [Makefile:17: .DEFAULT] Error 2 >>> gmake[1]: Leaving directory '/wrkdirs/usr/ports/multimedia/libvpx/work/libvpx-1.6.1' >>> ===> Compilation failed unexpectedly. >>> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to >>> the maintainer. >>> *** Error code 1 >>> >>> >>> >>> The arm_cpudetect.c code looks like it expects >>> for FreeBSD to define getauxval (but it does not) and >>> has alternate code it uses if is not >>> available: >> Correct. I've expected FreeBSD to either implement its own helper and >> put it somewhere like or mimic GNU. What actually happened >> is something in-between which tends to break existing code e.g., >> >>   AC_CHECK_HEADERS([sys/auxv.h]) >> >>   #ifdef HAVE_SYS_AUXV_H >>          unsigned long hwcap = getauxval(AT_HWCAP); >>   ... >>   #endif >> >> in https://github.com/mono/mono/blob/9ba3fa0ba37c/mono/utils/mono-hwcap-arm.c#L41 >> >> base r324815 has questionable rationale for not using getauxval() >> because if AT_FOO is not supported or doesn't make sense on FreeBSD one >> can just #ifdef it out. As you've noticed Linux folks rarely use >> getauxval() outside of AT_HWCAP. Some AT_* are compatible, some have >> different name, some are specific to Linux or FreeBSD. >> >> Now we have elf_aux_info() which is not documented. Go figure how to use >> it properly and avoid introducing bugs specific to FreeBSD. >> >> Makes one wonder why FreeBSD didn't choose sysctl to expose ARM >> capabilities like hw.cpu_features (on powerpc*) if portability was out >> of scope. > > It's my fault elf_aux_info() isn't documented yet. I agreed to write > the manpage, then I got sick (for weeks) and haven't gotten anything > much done in that time. > > I tend to agree about not providing a reasonably-compatible getauxval() > function being a bad thing.  I think it would be fine to support a > subset of the AT_* values linux supports, and we can add additional > support as needs arise. > Having linux compatible getauxval() was my original plan. But during testing, I found that some ports autodetect getauxval() presence and if exists, then full linux implementation is required. My bad is that I didn't realize that the presence of "sys/auxv/h" causes the same troubles. I don't think that full emulation of getauxval() is best - the port wants (from memory, incomplete) at least, additionally to AT_HWCAPS(2) : AT_PLATFORM AT_SECURE AT_RANDOM AT_CLKTCK I don't think that we want to implement linux compatible platform strings, nor generate random vector for each program. So, by my best, I think that FreeBSD specific version of original CPU/feature/platform function is easier and most robust solution. And, maybe, upstream will accept it at one day... The updated patch for multimedia/libvpx is here: http://build.humusoft.cz/patches/multimedia/libvpx/libvpx.diff Michal