Re: Clang buildworld failure due to multiple definitions of __isnanf

From: Eric McCorkle <eric_at_shadowsun.net>
Date: Tue, 28 Jun 2011 15:10:52 -0400
On 6/28/11 1:42 AM, Benjamin Kaduk wrote:
> On Tue, 28 Jun 2011, Benjamin Kaduk wrote:
>
>> On Mon, 27 Jun 2011, Eric McCorkle wrote:
>>
>>> make.conf:
>>> CPUTYPE?=core2
>>> .if !defined(CC) || ${CC} == "cc"
>>> CC=clang
>>> CFLAGS=-Qunused-arguments
>>> .endif
>>> .if !defined(CXX) || ${CXX} == "c++"
>>> CXX=clang++
>>> .endif
>>> NO_WERROR=
>>> WERROR=
>>> NO_FSCHG=
>>> PERL_VERSION=5.12.3
>>>
>>> Just noticed, the CFLAGS would disable optimization, which would
>>> explain why no one else seems to see this. Still, I think the
>>> underlying issue warrants investigation.
>>
>> I seem to recall that our gcc-4.2 with -O0 is known to be buggy --
>> certainly I just tripped over a panic in a third-party kernel module
>> build using bsd.kmod.mk with -O0 that was fixed by compiling the
>> object in question with -O.
>> It is not terribly easy to search for, but my archives find at least
>> http://lists.freebsd.org/pipermail/freebsd-current/2007-August/076028.html
>>
>>
>> I would try with -O1 and confirm that your issues go away, and not
>> spend time on the core issue if it proves to be a gcc bug.
>>
>> Unfortunately, we are stuck with an old gcc in base ... though I have
>> yet to see if clang -O0 has issues with my module.
>
> Wow, I juxtaposed the two compilers due to working on too little sleep.
> Please disregard, and sorry for the noise.
>

Getting rid of the CFLAGS in my make.conf got rid of the multiple 
definitions (I still think the underlying issue merits investigation and 
resolution) for both compilers.
Received on Tue Jun 28 2011 - 17:17:35 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC