svn commit: r324815 - in head: lib/libc/gen sys/sys

[Michal Meloun]

On 02.09.2018 18:44, Ian Lepore wrote:
> On Sun, 2018-09-02 at 16:16 +0200, Jan Beich wrote:
>> Michal Meloun <mmel at FreeBSD.org> writes:
>>
>>>
>>> Author: mmel
>>> Date: Sat Oct 21 12:06:18 2017
>>> New Revision: 324815
>>> URL: https://svnweb.freebsd.org/changeset/base/324815
>>>
>>> Log:
>>>   Make elf_aux_info() as public libc function.
>>>   - Teach elf aux vector functions about newly added AT_HWCAP and
>>> AT_HWCAP2
>>>     vectors.
>>>   - Export _elf_aux_info() as new public libc function
>>> elf_aux_info(3)
>>>   
>>>   The elf_aux_info(3) should be considered as FreeBSD counterpart
>>> of glibc
>>>   getauxval() with more robust interface.
>> Can you back it out? I've reported sys/auxv.h breaks existing
>> consumers
>> and the function is yet to be documented. 12.0-RELEASE is approaching
>> but there's no fix in sight, and by the time it lands there maybe
>> not enough time to test.
>>
>> http://docs.freebsd.org/cgi/mid.cgi?03a31eff-34e8-be4c-c008-528824fea
>> 261
>>
> 
> Are you seriously suggesting that freebsd is forbidden to add a system
> header file of any name it chooses, just because some port's autotools
> stuff mistakenly assumes the presence of that name implies something
> linux-specific? If the port is broken, fix it.
> 
> -- Ian
>
Jan,
I apologize for the late reply but right now I noticed this thread in my
spam folder. I don't know why gmail so classified it :(

I agree with Ian, the port should test getauxval() presence, not a
header file.
Moreover, at this point elf_aux_info () is the only function with which
we can implement FreeBSD specific version of the runtime hw feature
detection for ARM cpus. So I think revert is the worst option.
Do you know how many ports are affected? I only know about libvpx (for
which I immediately sent a fix) and (from memory) mono is also affected.

But, please remember, with or without the getauxval () emulation,
majority of ports will still need a patch.
Mainly because the cpu detection code is covered by #ifdef __linux__
and/or the port have hardcoded  #AT_<foo> values (we uses different
numbers for it) or so.
I ready to prepare patch for every single port affected by this problem,
simple list of problematic ports is enough.

Michal