Date: Fri, 8 Dec 2017 12:46:12 +0100 From: Michal Meloun <melounmichal@gmail.com> To: Ian Lepore <ian@freebsd.org>, Jan Beich <jbeich@FreeBSD.org>, Mark Millard <markmi@dsl-only.net> Cc: Freebsd-arm <freebsd-arm@freebsd.org>, FreeBSD Ports <freebsd-ports@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 <sys/auxv.h> expectation? Message-ID: <03a31eff-34e8-be4c-c008-528824fea261@freebsd.org> In-Reply-To: <1512583709.58601.49.camel@freebsd.org> References: <AE704C6E-E686-4EBC-8BB1-A041F2DC647C@dsl-only.net> <wp1z-bvw9-wny@FreeBSD.org> <1512583709.58601.49.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06.12.2017 19:08, Ian Lepore wrote: > On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote: >> Mark Millard <markmi@dsl-only.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?03a31eff-34e8-be4c-c008-528824fea261>