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.
