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?

Ian Lepore ian at freebsd.org
Wed Dec 6 18:08:36 UTC 2017


On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote:
> Mark Millard <markmi at 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.

-- Ian


More information about the freebsd-ports mailing list