On 02.09.2018 18:44, Ian Lepore wrote: > On Sun, 2018-09-02 at 16:16 +0200, Jan Beich wrote: >> Michal Meloun <[email protected]> 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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "[email protected]"
