Hi, So since you're looking into this I wanted to try and narrow down a way to recreate. It looks like if you touch any source file in the external dpdk build it will trigger the problem. In my case I did:
touch
build-root/build-vpp_debug-native/external/dpdk-19.05/lib/librte_mbuf/rte_mbuf.c
and hit an error about quicly includes not found (looks like my "fix" didn't
really work anyway).
Interestingly removing all the .dpdk-* files from
build-root/build-vpp_debug-native/external didn't cause anything to be rebuilt,
even removing the dpdk-19.05 directory therein didn't cause it to be rebuilt.
Only removing build-root/build-vpp_debug-native/external in it's entirety
caused a rebuild. This final step fixes the problem.
Second point of interest. It looks like dpdk gets built twice during the same
make session.
make[4]: Entering directory
'/home/chopps/net/w/vpp/build-root/build-vpp_debug-native/external/dpdk-19.05'
Configuration done using custom-config
== Build lib
...
================== Installing
/home/chopps/net/w/vpp/build-root/install-vpp_debug-native/external/
tar: Current ‘cpu_layout.py’ is newer or same age
tar: Current ‘dpdk-devbind.py’ is newer or same age
...
Installation in
/home/chopps/net/w/vpp/build-root/install-vpp_debug-native/external/ complete
make[4]: Leaving directory
'/home/chopps/net/w/vpp/build-root/build-vpp_debug-native/external/dpdk-19.05'
--- validating rdma-core 25.0 checksum
...
--- building ipsec-mb 0.52 - log:
/home/chopps/net/w/vpp/build-root/build-vpp_debug-native/external/ipsec-mb.build.log
--- installing ipsec-mb 0.52 - log:
/home/chopps/net/w/vpp/build-root/build-vpp_debug-native/external/ipsec-mb.install.log
make[4]: Entering directory
'/home/chopps/net/w/vpp/build-root/build-vpp_debug-native/external/dpdk-19.05'
Configuration done using custom-config
== Build lib
...
== Build drivers/net/e1000
CC rte_aesni_mb_pmd.o
== Build drivers/net/ena
== Build drivers/net/enetc
CC rte_aesni_mb_pmd_ops.o
== Build drivers/net/enic
== Build drivers/net/fm10k
CC aesni_gcm_pmd.o
PMDINFO rte_aesni_mb_pmd.o.pmd.c
CC rte_aesni_mb_pmd.o.pmd.o
CC aesni_gcm_pmd_ops.o
PMDINFO aesni_gcm_pmd.o.pmd.c
CC aesni_gcm_pmd.o.pmd.o
LD rte_aesni_mb_pmd.o
AR librte_pmd_aesni_mb.a
INSTALL-LIB librte_pmd_aesni_mb.a
== Build drivers/net/i40e
LD aesni_gcm_pmd.o
== Build drivers/net/iavf
== Build drivers/net/ice
AR librte_pmd_aesni_gcm.a
INSTALL-LIB librte_pmd_aesni_gcm.a
== Build drivers/net/ixgbe
..
However it seems to actually be doing things in the second run through so I
guess its needed?
Thanks,
Chris.
> On Sep 27, 2019, at 4:44 AM, Benoit Ganne (bganne) via Lists.Fd.Io
> <bganne=cisco....@lists.fd.io> wrote:
>
> Hi Chris,
>
> This is tricky... I've never ran into the issue even though I also build w/o
> ext-deps from time to time.
> My understanding of what could happen here: we have the top Makefile building
> external dependencies outside of the VPP cmake infra. So from VPP cmake PoV,
> those external libs are really external and it has no idea on how to build
> them. They are supposed to be there.
> In the plugins CMakeLists, we do check if those external lib are present. If
> they are not, we disable the build of the plugin. However this detection is
> done during cmake config phase, and cmake cache the results.
> So what could happen is you build the external libs, cmake found them and
> enable the plugin build. Later on you removed the external libs from the
> install dir and the top Makefile did not manage to detect the lib was missing
> and need rebuild. Then VPP cmake relies on its cache, tries to build the
> plugin and boom.
> I'll look into the build dep management in the top Makefile and external lib
> build system to see what's wrong.
>
> ben
>
>
>> -----Original Message-----
>> From: vpp-dev@lists.fd.io <vpp-dev@lists.fd.io> On Behalf Of Christian
>> Hopps
>> Sent: jeudi 26 septembre 2019 18:17
>> To: vpp-dev <vpp-dev@lists.fd.io>
>> Cc: Christian Hopps <cho...@chopps.org>
>> Subject: [vpp-dev] Odd build issue/failure.
>>
>> Locally we build VPP w/o installing ext deps (e.g., dpdk). This mostly
>> work fine, and allows us to easily make modifications to these external
>> libraries if we need to.
>>
>> Recently I've had issues with the build failing occasionally due to not
>> being able to find some external library, but only under certain
>> circumstances (seemingly when something in an external build rebuilds
>> itself, I haven't quite figured out what the trigger is).
>>
>> Here's an example of the failure with rdma plugin (I also saw and "fixed"
>> this with quic for which I include the diff below);
>>
>> -- Build files have been written to: /home/chopps/net/w/vpp/build-
>> root/build-vpp_debug-native/vpp
>> @@@@ Building vpp in /home/chopps/net/w/vpp/build-root/build-
>> vpp_debug-native/vpp @@@@
>> ninja: error: '/home/chopps/net/w/vpp/build-root/install-vpp_debug-
>> native/external/lib/libibverbs.a', needed by
>> 'lib/vpp_plugins/rdma_plugin.so', missing and no known rule to make it
>>
>> As mentioned above, I also have a fix that I can apply to the failing
>> plugin CMakefile; however, I don't fully understand what is going on and
>> so I'm not comfortable submitting it as a proposed fix.
>>
>> Can someone help describe what might be going on, or at least what the
>> correct fix is?
>>
>> Below is the diff which fixes this same issue for the quic plugin.
>>
>> Thanks,
>> Chris.
>>
>> 1 file changed, 12 insertions(+), 8 deletions(-)
>> src/plugins/quic/CMakeLists.txt | 20 ++++++++++++--------
>>
>> modified src/plugins/quic/CMakeLists.txt
>> @@ -20,14 +20,16 @@ find_library (QUICLY_LIBRARY NAMES "libquicly.a")
>> find_library (PICOTLS_CORE_LIBRARY NAMES "libpicotls-core.a")
>> find_library (PICOTLS_OPENSSL_LIBRARY NAMES "libpicotls-openssl.a")
>>
>> -list(APPEND QUIC_LINK_LIBRARIES
>> - ${QUICLY_LIBRARY}
>> - ${PICOTLS_CORE_LIBRARY}
>> - ${PICOTLS_OPENSSL_LIBRARY}
>> -)
>> +if(QUICLY_INCLUDE_DIR AND QUICLY_LIBRARY)
>> + get_filename_component(QUICLY_LIB_DIR ${QUICLY_LIBRARY} DIRECTORY)
>> + set(QUIC_LINK_FLAGS "-Wl,--whole-
>> archive,${QUICLY_LIB_DIR}/libquicly.a,--no-whole-archive")
>> +
>> + get_filename_component(PICOTLS_LIB_DIR ${PICOTLS_CORE_LIBRARY}
>> DIRECTORY)
>> + set(QUIC_LINK_FLAGS "${QUIC_LINK_FLAGS} -Wl,--whole-
>> archive,${PICOTLS_LIB_DIR}/libpicotls-core.a,--no-whole-archive")
>> +
>> + get_filename_component(PICOTLS_OPENSSL_LIB_DIR
>> ${PICOTLS_OPENSSL_LIBRARY} DIRECTORY)
>> + set(QUIC_LINK_FLAGS "${QUIC_LINK_FLAGS} -Wl,--whole-
>> archive,${PICOTLS_OPENSSL_LIB_DIR}/libpicotls-openssl.a,--no-whole-
>> archive")
>>
>> -if(QUICLY_INCLUDE_DIR AND QUIC_LINK_LIBRARIES)
>> - include_directories (${QUICLY_INCLUDE_DIR})
>> add_vpp_plugin(quic
>> SOURCES
>> certs.c
>> @@ -35,8 +37,10 @@ if(QUICLY_INCLUDE_DIR AND QUIC_LINK_LIBRARIES)
>> quic.c
>> quic_crypto.c
>>
>> - LINK_LIBRARIES ${QUIC_LINK_LIBRARIES}
>> + LINK_FLAGS
>> + ${QUIC_LINK_FLAGS}
>> )
>> + include_directories (${QUICLY_INCLUDE_DIR})
>> message(STATUS "Found quicly in ${QUICLY_INCLUDE_DIR}")
>> else()
>> message(WARNING "-- quicly not found - quic_plugin disabled")
>>
>> I've now hit the same issue with rdma and libibverbse
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#14072): https://lists.fd.io/g/vpp-dev/message/14072
> Mute This Topic: https://lists.fd.io/mt/34300592/1826170
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [cho...@chopps.org]
> -=-=-=-=-=-=-=-=-=-=-=-
signature.asc
Description: Message signed with OpenPGP
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14073): https://lists.fd.io/g/vpp-dev/message/14073 Mute This Topic: https://lists.fd.io/mt/34300592/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
