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?

Jan Beich jbeich at FreeBSD.org
Wed Dec 6 17:37:29 UTC 2017


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 <sys/auxv.h>
> for FreeBSD to define getauxval (but it does not) and
> has alternate code it uses if <sys/auxv.h> is not
> available:

Correct. I've expected FreeBSD to either implement its own helper and
put it somewhere like <libutil.h> 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.


More information about the freebsd-ports mailing list