Hi Jon, I have a conjecture. It is based on some experiences with previous projects I have worked on. I need to test this out before stating anything definite, but I will give you a heads up on what I will try experimentally, in case you wish to try it yourself. Consider the .am files in directory vpp/src, and look for any libraries that have a term ending in LIBADD. My experiment will be to comment out the ...LIBADD terms. If all goes well, the libraries that I am not adding via LIBADD are already added to the final binaries using LDADD. Otherwise I will see a build failure on ANY machine I try to build on.
If we get lucky, this is a problem I have wrestled with for 8 years. Unfortunately, in 8 years, I have not come up with a concise statement that points to when there is a failure. But I can say that it has exhibited an "almost random" effect in terms of build failures. Without a clear, concise statement and understanding, I am sticking my neck out. The worst case is "back to the drawing board." Once I have a chance to try this, I will only be able to say whether or not I am breaking the build. If I don't break the build, then your machine will be the place where we know if I have accomplished anything useful. Later, Burt On Thu, Jan 12, 2017 at 5:37 PM, Jon Loeliger <j...@netgate.com> wrote: > > > On Thu, Jan 12, 2017 at 3:10 PM, Jon Loeliger <j...@netgate.com> wrote: > >> >> jdl@localhost $ find . -name libvppinfra\* >> ./build-root/build-tool-native/tools/.libs/libvppinfra.so.0.0.0 >> ./build-root/build-tool-native/tools/.libs/libvppinfra.so.0 >> ./build-root/build-tool-native/tools/.libs/libvppinfra.so >> ./build-root/build-tool-native/tools/.libs/libvppinfra.a >> ./build-root/build-tool-native/tools/.libs/libvppinfra.lai >> ./build-root/build-tool-native/tools/.libs/libvppinfra.la >> ./build-root/build-tool-native/tools/libvppinfra.la >> ./build-root/tools/lib64/libvppinfra.so.0.0.0 >> ./build-root/tools/lib64/libvppinfra.so.0 >> ./build-root/tools/lib64/libvppinfra.so >> ./build-root/tools/lib64/libvppinfra.la >> ./build-root/tools/lib64/libvppinfra.a >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.so.0.0.0 >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.so.0 >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.so >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.a >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.lai >> ./build-root/build-vpp-native/vpp/.libs/libvppinfra.la >> ./build-root/build-vpp-native/vpp/libvppinfra.la >> >> And looking at that last link line with libtool: >> >> libtool: install: (cd >> /home/jdl/workspace/vpp/build-root/build-vpp-native/vpp; >> /bin/sh /home/jdl/workspace/vpp/build-root/build-vpp-native/vpp/libtool >> --silent --tag CC --mode=relink gcc -Wall -g -O2 -DFORTIFY_SOURCE=2 >> -march=corei7 -mtune=corei7-avx -fstack-protector -fPIC -Werror -g -O2 >> -DFORTIFY_SOURCE=2 -march=corei7 -mtune=corei7-avx -fstack-protector -fPIC >> -Werror -L/home/jdl/workspace/vpp/build-root/install-vpp-native/dpdk/lib >> -Wl,-rpath -Wl,/home/jdl/workspace/vpp/build-root/install-vpp-native/dpdk/lib >> -o libsvm.la -rpath /home/jdl/workspace/vpp/build- >> root/install-vpp-native/vpp/lib64 svm/svm.lo svm/ssvm.lo libvppinfra.la >> -lrt -lpthread ) >> >> Separate out the library crude for readability: >> >> -L/home/jdl/workspace/vpp/build-root/install-vpp-native/dpdk/lib >> -Wl,-rpath >> -Wl,/home/jdl/workspace/vpp/build-root/install-vpp-native/dpdk/lib >> -o libsvm.la >> -rpath /home/jdl/workspace/vpp/build-root/install-vpp-native/vpp/lib64 >> svm/svm.lo >> svm/ssvm.lo >> libvppinfra.la >> -lrt >> -lpthread >> >> Where is that -lvppinfra supposed to come from? >> >> Thanks, >> jdl >> >> > So, a side-by-side comparison of a working and this-non-working > build shows that the working build does an install of vppinfra, both > libraries and include files, that is missing from the non-working build. > > These: > > /usr/bin/mkdir -p '/home/jdl/workspace/ngr-rpms/ > build_root/BUILD/vpp/build-root/rpm/vpp-1.0.0/build-root/ins > tall-vpp-native/vpp/include/vppinfra' > libtool: install: /usr/bin/install -c .libs/libvppinfra.so.0.0.0 > /home/jdl/workspace/ngr-rpms/build_root/BUILD/vpp/build-root > /rpm/vpp-1.0.0/build-root/install-vpp-native/vpp/lib64/libvp > pinfra.so.0.0.0 > > /usr/bin/install -c -m 644 /home/jdl/workspace/ngr-rpms/ > build_root/BUILD/vpp/build-root/rpm/vpp-1.0.0/build-data/../ > src/vppinfra/asm_mips.h > [ snip ] > 1.0.0/build-data/../src/vppinfra/random_buffer.h > '/home/jdl/workspace/ngr-rpms/build_root/BUILD/vpp/build-roo > t/rpm/vpp-1.0.0/build-root/install-vpp-native/vpp/include/vppinfra' > > Not just vppinfra, other things (like vpctl) as well. > > Somehow skipped an install dependency? So, a Makefile difference > or make thing? Missing .PHONY or explicit dependency needed? > I appear to be running > > jdl@localhost $ make -v > GNU Make 3.82 > Built for x86_64-redhat-linux-gnu > > on both (good build, bad build) systems. > > Which led to an interesting experiment. I turned the -j ability > completely off on my build that has been working. Now serialized, > it too fails in the same way. > > I think it is exposing a missing dependency between an install > step, which needs to be completed, before this ssvm relink effort. > > Or maybe *within* the install step, it has to be sequenced properly. > > jdl > >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
