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 ucpp sal dependency (was Re: OpenOffice nightly)
Date Mon, 12 Dec 2011 14:09:37 GMT
On Tue, Dec 06, 2011 at 05:35:54PM -0300, Ariel Constenla-Haile wrote:
> 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.
> 
> 

now on Windows:

link 
/MACHINE:IX86 
/IGNORE:4102 
/IGNORE:4197 
@C:/cygwin/tmp/mkM2vC8q
-safeseh 
-nxcompat 
-dynamicbase 
-NODEFAULTLIB 
-DEBUG 
/SUBSYSTEM:CONSOLE
/BASE:0x1b000000 
-out:../../../../wntmsci12/bin/ucpp.exe
-map:../../../../wntmsci12/misc/ucpp.map

../../../../wntmsci12/obj/assert.obj 
../../../../wntmsci12/obj/cpp.obj
../../../../wntmsci12/obj/eval.obj 
../../../../wntmsci12/obj/hash.obj
../../../../wntmsci12/obj/lexer.obj 
../../../../wntmsci12/obj/macro.obj
../../../../wntmsci12/obj/mem.obj 
../../../../wntmsci12/obj/nhash.obj
msvcrtd.lib 
uwinapi.lib    <---- SAL dependency
kernel32.lib 
user32.lib 
oldnames.lib
stlport_vc71_stldebug.lib 


LINK : fatal error LNK1104: no se puede abrir el archivo 'uwinapi.lib'

dmake:  Error code 80, while making '../../../../wntmsci12/bin/ucpp.exe'
dmake:  Error code 255, while making
'./wntmsci12/misc/build/so_built_ucpp'


the solution for both errors on Linux and Windows seems to be

UWINAPILIB=$(0)
LIBSALCPPRT=$(0)

see 

xml2cmp/util/makefile.mk#49
soltools/testSHL/makefile.mk#38
soltools/javadep/makefile.mk#40


@J├╝rgen: please try the attached patch (it worked on Linux/Fedora and
WinXP)


Regards
-- 
Ariel Constenla-Haile
La Plata, Argentina

Mime
View raw message