Cool. My suggestion would not have solved the issue, but looking at
Damjan's .am files gives me a hint why the years ago project had issues,
for example:
libsvm_la_LIBADD = libvppinfra.la -lrt -lpthread
libsvm_la_DEPENDENCIES = libvppinfra.la
I'll bet we did not have the second line in the years ago project. (This is
just an example; the years ago problems were not VPP related.)
If anyone is interested in whether I could build after removing all the
LIBADD and related DEPENDENCIES in my experiment, the answer is: ALMOST. I
had to add this
if WITH_IPV6SR
bin_vpp_LDADD += -lcrypto
endif
in vpp.am. But I was able to remove more lines than I had to add back.
Burt
On Thu, Jan 12, 2017 at 7:46 PM, Jon Loeliger <j...@netgate.com> wrote:
>
>
> On Thu, Jan 12, 2017 at 5:40 PM, Damjan Marion <dmarion.li...@gmail.com>
> wrote:
>
>>
>> A few more details: this is race condition in parallel execution of “make
>> install” targets.
>> I am aware of the problem, but for me it was hard to troubleshoot as it
>> is not happening
>> in my system, and so far I noticed it only occasionaly in verify jobs.
>>
>> I think it was caused by:
>>
>> libvppinfradir = ${libdir}
>> libvppinfra_LTLIBRARIES = libvppinfra.la
>>
>> And is now fixed with:
>>
>> lib_LTLIBRARIES += libvppinfra.la
>>
>>
>> Basically by having 2 LTLIBRARIES groups, we were allowing Make to
>> install them in parallel.
>> As we are relinking libs during install, it was happening that that lib
>> was not there when
>> it was needed.
>>
>> Let me know if it works now, if not I have some other ideas what we can
>> do…
>>
>> Thanks,
>>
>> Damjan
>
>
> That does appear to have fixed it!
>
> Thank you!
>
> jdl
>
> PS -- Yes, I see it in top-of-tree as well!
>
>
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
