On 06.12.2017 19:08, Ian Lepore wrote:
On Wed, 2017-12-06 at 18:37 +0100, Jan Beich wrote:
Mark Millard <mar...@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
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
