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?

Michal Meloun melounmichal at gmail.com
Fri Dec 8 11:46:15 UTC 2017



On 06.12.2017 19:08, Ian Lepore wrote:
> 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.
> 

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






More information about the freebsd-ports mailing list