From owner-freebsd-arm@freebsd.org Wed Dec 6 18:08:36 2017 Return-Path: Delivered-To: freebsd-arm@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 CA5BBE87BD4 for ; Wed, 6 Dec 2017 18:08:36 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB81C7C4F5 for ; Wed, 6 Dec 2017 18:08:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5efd214d-dab0-11e7-b1c3-712f93d8ba90 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 5efd214d-dab0-11e7-b1c3-712f93d8ba90; Wed, 06 Dec 2017 18:07:50 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vB6I8T2L006547; Wed, 6 Dec 2017 11:08:29 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1512583709.58601.49.camel@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? From: Ian Lepore To: Jan Beich , Mark Millard Cc: Freebsd-arm , FreeBSD Ports Date: Wed, 06 Dec 2017 11:08:29 -0700 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Dec 2017 18:08:36 -0000 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. -- Ian