Date: Thu, 6 Sep 2018 14:36:00 +0200 From: Michal Meloun <melounmichal@gmail.com> To: Ian Lepore <ian@freebsd.org>, Jan Beich <jbeich@FreeBSD.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r324815 - in head: lib/libc/gen sys/sys Message-ID: <9b82bdaa-cc98-f53c-a0c0-d1e36239e947@freebsd.org> In-Reply-To: <1535906683.9486.20.camel@freebsd.org> References: <201710211206.v9LC6INJ032680@repo.freebsd.org> <5zzo-vvbu-wny@FreeBSD.org> <1535906683.9486.20.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02.09.2018 18:44, Ian Lepore wrote: > On Sun, 2018-09-02 at 16:16 +0200, Jan Beich wrote: >> Michal Meloun <mmel@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9b82bdaa-cc98-f53c-a0c0-d1e36239e947>