On Tue, Dec 06, 2011 at 08:40:26PM +0100, Mathias Bauer wrote: > Am 04.12.2011 21:50, schrieb Ariel Constenla-Haile: > > > On Sun, Dec 04, 2011 at 12:28:59AM -0300, Ariel Constenla-Haile wrote: > >> > >> Hi Andrew, > >> > >> On Sat, Dec 03, 2011 at 06:55:19PM -0800, Andrew Rist wrote: > >> > The nightly[1] has been updated and we have both RAT[2] and logs[3] now. > >> > Any help fixing the build would be great. > >> > Andrew > >> > > >> > [1] http://ci.apache.org/builders/openofficeorg-nightly/ > >> > [2] http://ci.apache.org/projects/openoffice/rat-output.html > >> > [3] > >> > http://ci.apache.org/projects/openoffice/buildlogs/log/unxlngx6.pro.build.html > >> > > >> > >> /bin/bash: > >> /home/buildslave19/slave19/openofficeorg-nightly/build/main/solver/340/unxlngx6.pro/bin/makedepend: > >> No such file or directory > >> > >> This module is missing a dependency on soltools (where makedepend is > >> built). Try the attached patch. > > > > on a clean build I noticed it also tries to link agains salcpprt, so you > > need to add sal to the dependency list. > > > > Regards > > This would be a bad idea. External sources (even patched ones) should > not have dependencies on OOo sources.
yes, this looked quit strange, and I didn't notice it was trying to link against salcpprt until I tested a clean build with only one process. It seems building with multi-processes is a bit tricky, because the build tries to go on as far as it can. So you may try to rebuild the broken module after build.pl stops, and it may seem to build find; in this case, sal seems to be build in parallel with that broken module, so you don't notice the dependency. > So it would be desirable to > replace any sal related code in external source code with some "native" > code. Besides that, I failed to see where ucpp might use something from > sal: the patch file only creates a dmake makefile and leaves the > original sources untouched. Why should it have any dependencies on sal? yes, quite strange. The build breaks, here is the command: g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=both -Wl,-rpath,'$ORIGIN/../../ure-link/lib' -Wl,-export-dynamic -Wl,--noinhibit-exec -Wl,-rpath-link,../../../../unxlngx6/lib:/mnt/build/openoffice/apache/trunk/main/solver/340/unxlngx6/lib:/lib:/usr/lib -L../../../../unxlngx6/lib -L../lib -L/mnt/build/openoffice/apache/trunk/main/solenv/unxlngx6/lib -L/mnt/build/openoffice/apache/trunk/main/solver/340/unxlngx6/lib -L/mnt/build/openoffice/apache/trunk/main/solenv/unxlngx6/lib -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/lib64 -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64 -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server -L/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/native_threads -L/usr/lib64 ../../../../unxlngx6/obj/assert.o ../../../../unxlngx6/obj/cpp.o ../../../../unxlngx6/obj/eval.o ../../../../unxlngx6/obj/hash.o ../../../../unxlngx6/obj/lexer.o ../../../../unxlngx6/obj/macro.o ../../../../unxlngx6/obj/mem.o ../../../../unxlngx6/obj/nhash.o \ -Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive <===== SAL dependency -Wl,--as-needed -ldl -lpthread -lm -Wl,--no-as-needed -o ../../../../unxlngx6/bin/ucpp /usr/bin/ld: cannot find -lsalcpprt collect2: ld returned 1 exit status dmake: Error code 1, while making '../../../../unxlngx6/bin/ucpp' dmake: Error code 255, while making './unxlngx6/misc/build/so_built_ucpp' So, it does try to link against ucpp. The switch seems to come from solenv/inc/unxlng.mk#226 LIBSALCPPRT*=-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive As a unxlng specific thing, it affect also that buildbot. Somewhere, on the build env. that switch is added. May be there is another case where OOo does not use/patch the original make Makefile, and instead uses dmake; this error may be reproducible also in that cases. Regards -- Ariel Constenla-Haile La Plata, Argentina
pgphwtk6mfNCm.pgp
Description: PGP signature
