Date: Tue, 09 Jun 2015 18:15:38 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends Message-ID: <55778FBA.5010004@pinyon.org> In-Reply-To: <Pine.GSO.4.64.1506092102460.10480@sea.ntplx.net> References: <55777108.5020206@pinyon.org> <Pine.GSO.4.64.1506091940001.10480@sea.ntplx.net> <55778A60.9090200@pinyon.org> <Pine.GSO.4.64.1506092054570.10480@sea.ntplx.net> <Pine.GSO.4.64.1506092102460.10480@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/09/15 18:03, Daniel Eischen wrote:
> On Tue, 9 Jun 2015, Daniel Eischen wrote:
>
>> On Tue, 9 Jun 2015, Russell L. Carter wrote:
>>
>>> On FreeBSD 10-stable r283752 amd64, here is the compile line:
>>>
>>> /usr/bin/cc -O -Wall tester.cpp -o tester
>>> /tmp/tester-b681b3.o: In function `main':
>>> tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)'
>>> tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)'
>>>
>>> Compilers don't matter, linking against libthr or libstdthreads
>>> doesn't matter.
>>
>> Is cc doing something special because it thinks it is C++?
>> I'm on 10-stable amd64 and that example (saved as tester.c)
>> works just fine.
Yep! That made me laugh. I generally test as c++ and I thought I
would cut this one down to just c, but that extension matters to every
c compiler I tried.
Putting the standard extern "C" { ... } guards around
#include<sys/utmp.h> cures this problem.
Thanks!
Russell
>
> Try:
>
> /usr/bin/cc -O -Wall -x c tester.cpp -o tester
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55778FBA.5010004>