On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote: > Mark Millard <[email protected]> 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
