incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <arie...@apache.org>
Subject Re: OpenOffice nightly
Date Tue, 06 Dec 2011 20:35:54 GMT
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

Mime
View raw message