incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <jogischm...@googlemail.com>
Subject Re: ucpp sal dependency (was Re: OpenOffice nightly)
Date Wed, 14 Dec 2011 08:44:27 GMT
On 12/12/11 3:09 PM, Ariel Constenla-Haile wrote:
> 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)

it worked under MacOS as well, will you commit it? The missing 
dependency has been already applied by Pavel.

Juergen

>
>
> Regards


Mime
View raw message