You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Ariel Constenla-Haile <ar...@apache.org> on 2011/12/12 15:09:37 UTC
ucpp sal dependency (was Re: OpenOffice nightly)
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
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Jürgen,
On Wed, Dec 14, 2011 at 09:44:27AM +0100, Jürgen Schmidt wrote:
> >@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.
done
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 14.12.2011 22:44, schrieb Michael Stahl:
> On 13/12/11 17:01, Jürgen Schmidt wrote:
>
>>> BTW: another fix for the current problem would be converting ucpp to
>>> gbuild.
>>
>> i would love to do that, do you know if it's already possible to use
>> gbuild to apply our patch process and trigger a build on the patched
>> sources?
>
> not yet :(
>
> such an effort was not started during OOo times.
I worked on it for a few days somewhere in summer.
>
> there has been some work on this in LO but we don't yet build any external
> by default with gbuild...
>
> well, you could always use a CustomTarget to do it, but i guess it is very
> cumbersome that way...
Whether or not you do it with a CustomTarget, the most nasty problem was
to get clean dependencies - the essence of the gbuild idea. The pure
command execution seemed rather trivial compared with that.
Regards,
Mathias
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Michael Stahl <ms...@openoffice.org>.
On 13/12/11 17:01, Jürgen Schmidt wrote:
>> BTW: another fix for the current problem would be converting ucpp to
>> gbuild.
>
> i would love to do that, do you know if it's already possible to use
> gbuild to apply our patch process and trigger a build on the patched
> sources?
not yet :(
such an effort was not started during OOo times.
there has been some work on this in LO but we don't yet build any external
by default with gbuild...
well, you could always use a CustomTarget to do it, but i guess it is very
cumbersome that way...
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Pedro Giffuni <pf...@apache.org>.
Hello,
--- Mar 13/12/11, Jürgen Schmidt ha scritto:
> >
> > BTW: another fix for the current problem would be
> > converting ucpp to gbuild.
>
> i would love to do that, do you know if it's already
> possible to use gbuild to apply our patch process
> and trigger a build on the patched sources?
>
FWIW, in this case you don't need to patch, at least
not C files. If gbuild can manage to use the existing
Makefile we would be all set.
cheers,
Pedro.
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Mathias Bauer <Ma...@gmx.net>.
Am 13.12.2011 17:01, schrieb Jürgen Schmidt:
>> BTW: another fix for the current problem would be converting ucpp to
>> gbuild.
>
> i would love to do that, do you know if it's already possible to use
> gbuild to apply our patch process and trigger a build on the patched
> sources?
No, that would be the part to implement. In another life ;-) I already
started working on that, but didn't get very far.
Regards,
Mathias
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On 12/13/11 10:25 AM, Mathias Bauer wrote:
> On 12.12.2011 15:09, Ariel Constenla-Haile wrote:
>
>> 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)
>
> Yes, that's the "unfortunate magic" I mentioned that the old build
> system applies. uwinapi.dll is part of the standard set of libraries
> that our dmake based build system uses automatically.
>
> This automatic linkage against uwinapi.dll is a desperate attempt. The
> purpose of this library is to fix bugs in the Windows API by providing a
> wrapper with functions that have the same name as the buggy ones.
> Linking against that library before any Windows library is seen prevents
> the call of the buggy code.
>
> uwinapi.dll was definitely needed on Win9x (here it might have served as
> a UniCode wrapper also, I'm not sure), but AFAIR also for some Windows
> API functions on Win2000 and WinXP. The problem with non-automatic
> linking against uwinapi.dll was that developers needed to know which Win
> API functions they use and if one of them is one of the buggy ones at
> least on one OS version. Obviously there wasn't enough trust that
> developers would be able to track that, so uwinapi.dll was linked to
> everything on Windows.
>
> Perhaps it is worth the effort to check how much of uwinapi is still
> needed because the only possible platform that could benefit from it
> would be WinXP - and possibly some of the bugs have been fixed in
> service packs anyway. Getting rid of uwinapi would be nice.
>
> BTW: another fix for the current problem would be converting ucpp to
> gbuild.
i would love to do that, do you know if it's already possible to use
gbuild to apply our patch process and trigger a build on the patched
sources?
Juergen
>
>> LIBSALCPPRT=$(0)
>
> Interesting, I didn't know that that such magic is active on Linux also
> (though I suspected that).
>
> Good catch!
>
> Regards,
> Mathias
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Mathias Bauer <ma...@numberfour.eu>.
On 12.12.2011 15:09, Ariel Constenla-Haile wrote:
> 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)
Yes, that's the "unfortunate magic" I mentioned that the old build
system applies. uwinapi.dll is part of the standard set of libraries
that our dmake based build system uses automatically.
This automatic linkage against uwinapi.dll is a desperate attempt. The
purpose of this library is to fix bugs in the Windows API by providing a
wrapper with functions that have the same name as the buggy ones.
Linking against that library before any Windows library is seen prevents
the call of the buggy code.
uwinapi.dll was definitely needed on Win9x (here it might have served as
a UniCode wrapper also, I'm not sure), but AFAIR also for some Windows
API functions on Win2000 and WinXP. The problem with non-automatic
linking against uwinapi.dll was that developers needed to know which Win
API functions they use and if one of them is one of the buggy ones at
least on one OS version. Obviously there wasn't enough trust that
developers would be able to track that, so uwinapi.dll was linked to
everything on Windows.
Perhaps it is worth the effort to check how much of uwinapi is still
needed because the only possible platform that could benefit from it
would be WinXP - and possibly some of the bugs have been fixed in
service packs anyway. Getting rid of uwinapi would be nice.
BTW: another fix for the current problem would be converting ucpp to gbuild.
> LIBSALCPPRT=$(0)
Interesting, I didn't know that that such magic is active on Linux also
(though I suspected that).
Good catch!
Regards,
Mathias
Re: ucpp sal dependency (was Re: OpenOffice nightly)
Posted by Jürgen Schmidt <jo...@googlemail.com>.
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