dhcpcd-discuss

On 02/10/2017 10:39, M. Buecher wrote:
> On 2017-10-01 23:26, Roy Marples wrote:
>> On 01/10/2017 20:48, M. Buecher wrote:
>>> It builds except for one error:
>>> ../../src/eloop.o: In function `eloop_event_add_rw':
>>> ./src/eloop.c:353: undefined reference to `reallocarray'
>>> collect2: error: ld returned 1 exit status
>>> Makefile:39: recipe for target 'eloop-bench' failed
>>>
>>> Don't know if this a source or Raspbian/Debian issue.
>>> Anybody got a clue?
>>
>> I can replicate it on my Sparky Linux image.
>> But it's tempermental, I can't always replicate it.
>>
>> I *think* it's a bug with GNU make - I cannot replicate it on any BSD
>> platform but then reallocarray is also present so that particular
>> issue would never be hit either.
>>
>> When it happens, I was able to build simply by touching src/eloop.c.
>> This changes the datetime, which make does use, implying it's a make
>> issue, or maybe an issue with my Makefile, but I don't understand what
>> or how.
>>
>> The eloop_bench isn't really a test, it just measures performance of
>> the chosen polling mechanism. I wrote it to highlight an issue with
>> the kqueue implementation on NetBSD compared to other BSDs. Linux of
>> course uses epoll.
>>
>> Roy
> 
> Just touching src/eloop.c didn't work for Raspbian/Debian and debuild.
> 
> From what I have seen so far my best guess is that
> "compat/reallocarray.o" is not available for linking. Just guessing as
> in the related call I cannot see that object referenced.
> 
> cc  -Wl,-z,relro -Wl,-z,now -o eloop-bench eloop-bench.o ../../src/eloop.o

It's not used.
CFLAGS sets -DNO_CONFIG_H so eloop will use it's internal version.

Is something else setting HAVE_REALLOCARRAY maybe?

Roy