Date: Wed, 06 Dec 2017 18:37:10 +0100 From: Jan Beich <jbeich@FreeBSD.org> To: 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: <wp1z-bvw9-wny@FreeBSD.org> In-Reply-To: <AE704C6E-E686-4EBC-8BB1-A041F2DC647C@dsl-only.net> (Mark Millard's message of "Wed, 6 Dec 2017 01:45:02 -0800") References: <AE704C6E-E686-4EBC-8BB1-A041F2DC647C@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?wp1z-bvw9-wny>