subject:"Re\: Building on Windows"

Sorry, "output" was ambiguous. I'm not interested in the log files at 
this time, but in the installation files. I want to try to install the 
result of your build on a Windows 7 machine.


On 9/19/2016 6:22 PM, John D'Orazio wrote:

I wound up building in stages, since the build was breaking here and there.
I just picked it up from where it left off as I fixed things. So I don't
have a single output... unless there is a log file that collects various
build stages together into one single output?
I would also recommend installing as many packages in cygwin as possible
without going through the extra step of installing lynx or apt-cyg... While
that does make the environment more similar to a linux build environment,
it's still an extra step and I believe it could be indicated as a second
possibliity. Somewhere in the Step by Step guide I added which packages to
choose in the cygwin interface if installing them from the cygwin
interface. I think installing the packages from the cygwin interface should
be indicated as the first step to take when first installing cygwin, adding
all the necessary packages along with the first install.
The only package I couldn't find from the cygwin interface was the Perl
LWP::UserAgent package, so I installed that using "cpan -i LWP::UserAgent".


On Tue, Sep 20, 2016 at 12:25 AM, Patricia Shanahan  wrote:


Congratulations! I'm about to do a Windows 10 build on a new machine, so
please make sure the step-by-step incorporates all that you learned in the
process.

I have a specific test I would like run. The current release process calls
for doing the Windows builds on Windows 7. I am wondering if that is
necessary. Could you test your Windows 10 build on a Windows 7 machine? Or
send me the output - that may be quicker than waiting for my Windows 10
build to go through.


On 9/19/2016 1:46 PM, John D'Orazio wrote:


I have now successfully completed the build on Windows 10, and after
changing the install path of NSIS to one without spaces, packaging also
completed successfully. I have added "Windows 10" alongside "Windows 7"
and
"Windows 8.1" in the Step by Step guide.

On Mon, Sep 19, 2016 at 7:50 PM, Patricia Shanahan  wrote:

I had installed 64-bit Cygwin installed here before I started on compiling

AOO. I hit problems, and had to go to the recommended 32-bit Cygwin.

However, things have changed a bit since then, so it may be worth seeing
if it works.

On 9/19/2016 8:59 AM, John D'Orazio wrote:
...

I also read somewhere that maybe using 64 bit cygwin can resolve the

occupied addresses and child_fork_process errors. I made an attempt at
getting the build environment ready in 64 bit cygwin but configure is
complaining about not finding Visual Studio C++, while this does not
happen
in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't
have
any problem finding it... I'm reading it has something to do with
registry
keys, idk I have to look into this better).

...



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building on Windows 10 breaks at guistdio.exe

4.1.3 does have changes to the language library URLs. Has anyone else 
done a build that included Italian?


On 9/19/2016 6:33 PM, John D'Orazio wrote:

I actually did see an error in the packaging phase, but it didn't seem to
affect the final output, I still got the setup.exe which worked just fine,
and I can open and use soffice.exe just fine after running setup. This is
the error I got:
ERROR: The following errors occurred in packaging process:

  273.923309 : ERROR: D:/NSIS/makensis.exe
D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it/downloadtemplate.nsi | !
  273.923514 : !include: error in script:
"D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it\Italian_pack.nsh" on line 10
  273.923550 : Error in macro LANGFILE_INCLUDE on macroline 11
  273.923588 : Error in macro MUI_LANGUAGE_PACK on macroline 12
  273.923619 : Error in script
"D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it/downloadtemplate.nsi" on line
270 -- aborting creation process

Not sure what that might affect.

Also, here are my final working configure settings:

SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"

./configure --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b
%Y)")"
--with-directx-home="D:\Microsoft_DirectX_SDK_June_2010"
--with-frame-home="D:/Microsoft_SDKs/Windows/v7.0"
--with-psdk-home="D:/Microsoft_SDKs/Windows/v7.0"
--with-midl-path="D:/Microsoft_SDKs/Windows/v7.0/bin"
--with-ant-home="/cygdrive/d/apache-ant/apache-ant-1.9.7"
--with-nsis-path="D:/NSIS"
--with-jdk-home="C:/PROGRA~2/Java/JDK18~1.0_7"
--with-csc-path="C:/Windows/Microsoft.NET/Framework/v3.5"
--with-cl-home="C:/PROGRA~2/MI1DCA~1.0/VC"
--with-asm-home="C:/PROGRA~2/MI1DCA~1.0/VC/bin"
--with-mozilla-build="/cygdrive/d/mozilla-build"
--with-atl-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/atl71
--with-atl-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/ATL/i386
--with-mfc-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/mfc42
--with-mfc-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/Mfc/i386
--with-dmake-url="
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2;
--with-epm-url="
https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz;
--without-junit
--without-stlport
--enable-win-x64-shellext
--enable-wiki-publisher
--enable-category-b
--enable-bundled-dictionaries
--with-lang="en-US it"

For those cases where I couldn't customize the install path, I used the
cygpath tool to get the shortened path as suggested on this page
https://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows#configure
(e.g. cygpath -m -s "C:\Path With Spaces\That Needs Shortening").




On Tue, Sep 20, 2016 at 3:22 AM, John D'Orazio <
john.dora...@cappellaniauniroma3.org> wrote:


I wound up building in stages, since the build was breaking here and
there. I just picked it up from where it left off as I fixed things. So I
don't have a single output... unless there is a log file that collects
various build stages together into one single output?
I would also recommend installing as many packages in cygwin as possible
without going through the extra step of installing lynx or apt-cyg... While
that does make the environment more similar to a linux build environment,
it's still an extra step and I believe it could be indicated as a second
possibliity. Somewhere in the Step by Step guide I added which packages to
choose in the cygwin interface if installing them from the cygwin
interface. I think installing the packages from the cygwin interface should
be indicated as the first step to take when first installing cygwin, adding
all the necessary packages along with the first install.
The only package I couldn't find from the cygwin interface was the Perl
LWP::UserAgent package, so I installed that using "cpan -i LWP::UserAgent".


On Tue, Sep 20, 2016 at 12:25 AM, Patricia Shanahan  wrote:


Congratulations! I'm about to do a Windows 10 build on a new machine, so
please make sure the step-by-step incorporates all that you learned in the
process.

I have a specific test I would like run. The current release process
calls for doing the Windows builds on Windows 7. I am wondering if that is
necessary. Could you test your Windows 10 build on a Windows 7 machine? Or
send me the output - that may be quicker than waiting for my Windows 10
build to go through.


On 9/19/2016 1:46 PM, John D'Orazio wrote:


I have now successfully completed the build on Windows 10, and after
changing the install path of NSIS to one without spaces, packaging also
completed successfully. I have added "Windows 10" alongside "Windows 7"
and
"Windows 8.1" in the Step by Step guide.

On Mon, Sep 19, 2016 at 7:50 PM, Patricia

Re: building on Windows 10 breaks at guistdio.exe

I actually did see an error in the packaging phase, but it didn't seem to
affect the final output, I still got the setup.exe which worked just fine,
and I can open and use soffice.exe just fine after running setup. This is
the error I got:
ERROR: The following errors occurred in packaging process:

  273.923309 : ERROR: D:/NSIS/makensis.exe
D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it/downloadtemplate.nsi | !
  273.923514 : !include: error in script:
"D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it\Italian_pack.nsh" on line 10
  273.923550 : Error in macro LANGFILE_INCLUDE on macroline 11
  273.923588 : Error in macro MUI_LANGUAGE_PACK on macroline 12
  273.923619 : Error in script
"D:/source/aoo-trunk/main/instsetoo_native/
wntmsci12.pro/Apache_OpenOffice/msi/nsis/it/downloadtemplate.nsi" on line
270 -- aborting creation process

Not sure what that might affect.

Also, here are my final working configure settings:

SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"

./configure --with-build-version="$(date +"%Y-%m-%d %H:%M:%S (%a, %d %b
%Y)")"
--with-directx-home="D:\Microsoft_DirectX_SDK_June_2010"
--with-frame-home="D:/Microsoft_SDKs/Windows/v7.0"
--with-psdk-home="D:/Microsoft_SDKs/Windows/v7.0"
--with-midl-path="D:/Microsoft_SDKs/Windows/v7.0/bin"
--with-ant-home="/cygdrive/d/apache-ant/apache-ant-1.9.7"
--with-nsis-path="D:/NSIS"
--with-jdk-home="C:/PROGRA~2/Java/JDK18~1.0_7"
--with-csc-path="C:/Windows/Microsoft.NET/Framework/v3.5"
--with-cl-home="C:/PROGRA~2/MI1DCA~1.0/VC"
--with-asm-home="C:/PROGRA~2/MI1DCA~1.0/VC/bin"
--with-mozilla-build="/cygdrive/d/mozilla-build"
--with-atl-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/atl71
--with-atl-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/ATL/i386
--with-mfc-include-dir=/cygdrive/c/WinDDK/7600.16385.1/inc/mfc42
--with-mfc-lib-dir=/cygdrive/c/WinDDK/7600.16385.1/lib/Mfc/i386
--with-dmake-url="
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2;
--with-epm-url="
https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz;
--without-junit
--without-stlport
--enable-win-x64-shellext
--enable-wiki-publisher
--enable-category-b
--enable-bundled-dictionaries
--with-lang="en-US it"

For those cases where I couldn't customize the install path, I used the
cygpath tool to get the shortened path as suggested on this page
https://wiki.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Windows#configure
(e.g. cygpath -m -s "C:\Path With Spaces\That Needs Shortening").




On Tue, Sep 20, 2016 at 3:22 AM, John D'Orazio <
john.dora...@cappellaniauniroma3.org> wrote:

> I wound up building in stages, since the build was breaking here and
> there. I just picked it up from where it left off as I fixed things. So I
> don't have a single output... unless there is a log file that collects
> various build stages together into one single output?
> I would also recommend installing as many packages in cygwin as possible
> without going through the extra step of installing lynx or apt-cyg... While
> that does make the environment more similar to a linux build environment,
> it's still an extra step and I believe it could be indicated as a second
> possibliity. Somewhere in the Step by Step guide I added which packages to
> choose in the cygwin interface if installing them from the cygwin
> interface. I think installing the packages from the cygwin interface should
> be indicated as the first step to take when first installing cygwin, adding
> all the necessary packages along with the first install.
> The only package I couldn't find from the cygwin interface was the Perl
> LWP::UserAgent package, so I installed that using "cpan -i LWP::UserAgent".
>
>
> On Tue, Sep 20, 2016 at 12:25 AM, Patricia Shanahan  wrote:
>
>> Congratulations! I'm about to do a Windows 10 build on a new machine, so
>> please make sure the step-by-step incorporates all that you learned in the
>> process.
>>
>> I have a specific test I would like run. The current release process
>> calls for doing the Windows builds on Windows 7. I am wondering if that is
>> necessary. Could you test your Windows 10 build on a Windows 7 machine? Or
>> send me the output - that may be quicker than waiting for my Windows 10
>> build to go through.
>>
>>
>> On 9/19/2016 1:46 PM, John D'Orazio wrote:
>>
>>> I have now successfully completed the build on Windows 10, and after
>>> changing the install path of NSIS to one without spaces, packaging also
>>> completed successfully. I have added "Windows 10" alongside "Windows 7"
>>> and
>>> "Windows 8.1" in the Step by Step guide.
>>>
>>> On Mon, Sep 19, 2016 at 7:50 PM, Patricia Shanahan  wrote:
>>>
>>> I had installed 64-bit

Re: building on Windows 10 breaks at guistdio.exe

I wound up building in stages, since the build was breaking here and there.
I just picked it up from where it left off as I fixed things. So I don't
have a single output... unless there is a log file that collects various
build stages together into one single output?
I would also recommend installing as many packages in cygwin as possible
without going through the extra step of installing lynx or apt-cyg... While
that does make the environment more similar to a linux build environment,
it's still an extra step and I believe it could be indicated as a second
possibliity. Somewhere in the Step by Step guide I added which packages to
choose in the cygwin interface if installing them from the cygwin
interface. I think installing the packages from the cygwin interface should
be indicated as the first step to take when first installing cygwin, adding
all the necessary packages along with the first install.
The only package I couldn't find from the cygwin interface was the Perl
LWP::UserAgent package, so I installed that using "cpan -i LWP::UserAgent".

On Tue, Sep 20, 2016 at 12:25 AM, Patricia Shanahan  wrote:

> Congratulations! I'm about to do a Windows 10 build on a new machine, so
> please make sure the step-by-step incorporates all that you learned in the
> process.
>
> I have a specific test I would like run. The current release process calls
> for doing the Windows builds on Windows 7. I am wondering if that is
> necessary. Could you test your Windows 10 build on a Windows 7 machine? Or
> send me the output - that may be quicker than waiting for my Windows 10
> build to go through.
>
>
> On 9/19/2016 1:46 PM, John D'Orazio wrote:
>
>> I have now successfully completed the build on Windows 10, and after
>> changing the install path of NSIS to one without spaces, packaging also
>> completed successfully. I have added "Windows 10" alongside "Windows 7"
>> and
>> "Windows 8.1" in the Step by Step guide.
>>
>> On Mon, Sep 19, 2016 at 7:50 PM, Patricia Shanahan  wrote:
>>
>> I had installed 64-bit Cygwin installed here before I started on compiling
>>> AOO. I hit problems, and had to go to the recommended 32-bit Cygwin.
>>>
>>> However, things have changed a bit since then, so it may be worth seeing
>>> if it works.
>>>
>>> On 9/19/2016 8:59 AM, John D'Orazio wrote:
>>> ...
>>>
>>> I also read somewhere that maybe using 64 bit cygwin can resolve the
 occupied addresses and child_fork_process errors. I made an attempt at
 getting the build environment ready in 64 bit cygwin but configure is
 complaining about not finding Visual Studio C++, while this does not
 happen
 in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't
 have
 any problem finding it... I'm reading it has something to do with
 registry
 keys, idk I have to look into this better).

 ...
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

-- 
John R. D'Orazio

Re: building on Windows 10 breaks at guistdio.exe

Congratulations! I'm about to do a Windows 10 build on a new machine, so 
please make sure the step-by-step incorporates all that you learned in 
the process.


I have a specific test I would like run. The current release process 
calls for doing the Windows builds on Windows 7. I am wondering if that 
is necessary. Could you test your Windows 10 build on a Windows 7 
machine? Or send me the output - that may be quicker than waiting for my 
Windows 10 build to go through.


On 9/19/2016 1:46 PM, John D'Orazio wrote:

I have now successfully completed the build on Windows 10, and after
changing the install path of NSIS to one without spaces, packaging also
completed successfully. I have added "Windows 10" alongside "Windows 7" and
"Windows 8.1" in the Step by Step guide.

On Mon, Sep 19, 2016 at 7:50 PM, Patricia Shanahan  wrote:


I had installed 64-bit Cygwin installed here before I started on compiling
AOO. I hit problems, and had to go to the recommended 32-bit Cygwin.

However, things have changed a bit since then, so it may be worth seeing
if it works.

On 9/19/2016 8:59 AM, John D'Orazio wrote:
...


I also read somewhere that maybe using 64 bit cygwin can resolve the
occupied addresses and child_fork_process errors. I made an attempt at
getting the build environment ready in 64 bit cygwin but configure is
complaining about not finding Visual Studio C++, while this does not
happen
in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't
have
any problem finding it... I'm reading it has something to do with registry
keys, idk I have to look into this better).


...


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building on Windows 10 breaks at guistdio.exe

I have now successfully completed the build on Windows 10, and after
changing the install path of NSIS to one without spaces, packaging also
completed successfully. I have added "Windows 10" alongside "Windows 7" and
"Windows 8.1" in the Step by Step guide.

On Mon, Sep 19, 2016 at 7:50 PM, Patricia Shanahan  wrote:

> I had installed 64-bit Cygwin installed here before I started on compiling
> AOO. I hit problems, and had to go to the recommended 32-bit Cygwin.
>
> However, things have changed a bit since then, so it may be worth seeing
> if it works.
>
> On 9/19/2016 8:59 AM, John D'Orazio wrote:
> ...
>
>> I also read somewhere that maybe using 64 bit cygwin can resolve the
>> occupied addresses and child_fork_process errors. I made an attempt at
>> getting the build environment ready in 64 bit cygwin but configure is
>> complaining about not finding Visual Studio C++, while this does not
>> happen
>> in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't
>> have
>> any problem finding it... I'm reading it has something to do with registry
>> keys, idk I have to look into this better).
>>
> ...
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
John R. D'Orazio

Re: building on Windows 10 breaks at guistdio.exe

I had installed 64-bit Cygwin installed here before I started on 
compiling AOO. I hit problems, and had to go to the recommended 32-bit 
Cygwin.


However, things have changed a bit since then, so it may be worth seeing 
if it works.


On 9/19/2016 8:59 AM, John D'Orazio wrote:
...

I also read somewhere that maybe using 64 bit cygwin can resolve the
occupied addresses and child_fork_process errors. I made an attempt at
getting the build environment ready in 64 bit cygwin but configure is
complaining about not finding Visual Studio C++, while this does not happen
in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't have
any problem finding it... I'm reading it has something to do with registry
keys, idk I have to look into this better).

...

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: building on Windows 10 breaks at guistdio.exe

I installed some more things in my build environment such as the Windows
Drive Kit and I enabled the atl flags. I cleaned the whole build and
started over again with new config and using the multiprocessor and multi
threading capability, and have now made it close to the end of the build.
Only the last instsetoo_native module remains.

This last module is not completing, I keep getting perl child_fork_process
issues with address already busy etc.

I've been trying with solutions I'm finding online with a dash rebaseall,
haven't succeeded yet but will attempt again shortly.

I also read somewhere that maybe using 64 bit cygwin can resolve the
occupied addresses and child_fork_process errors. I made an attempt at
getting the build environment ready in 64 bit cygwin but configure is
complaining about not finding Visual Studio C++, while this does not happen
in 32 bit cygwin (I'm passing in the with-cl-home flag so it shouldn't have
any problem finding it... I'm reading it has something to do with registry
keys, idk I have to look into this better).

On Sep 18, 2016 20:05, "Patricia Shanahan"  wrote:

> Please excuse the delay responding - I put it aside hoping that someone
> with more knowledge would respond, and then got involved in other things.
>
> One possibility is that solver/420/wntmsci12.pro/xml/ was partially built
> due to an earlier failure. I suggest deleting solver/420/wntmsci12.pro
> and trying again.
>
> On 9/15/2016 5:52 AM, John D'Orazio wrote:
>
>> Patricia you are correct, after a few more attempts the desktop module did
>> build successfully. Now I'm up to the postprocess module, with this error:
>>
>> Entering /cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents
>>
>> dmake:  Error: -- `/cygdrive/d/source/aoo-trunk/main/solver/420/
>> wntmsci12.pro/xml/chartcontroller.component' not found, and can't be made
>>
>> 1 module(s):
>> postprocess
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents
>>
>> When you have fixed the errors in that module you can resume the build by
>> running:
>>
>> build --all:postprocess
>>
>>
>> Any ideas on this "chartcontroller.component"?
>>
>>
>> On Wed, Sep 14, 2016 at 11:58 PM, John D'Orazio <
>> john.dora...@cappellaniauniroma3.org> wrote:
>>
>> If it can be of any use to understand better the problem, I'm using this
>>> configuration:
>>>
>>> SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"
>>>
>>> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
>>> --with-midl-path="$SDK_PATH/bin" --with-directx-home="D:\
>>> Microsoft_DirectX_SDK_June_2010" --with-ant-home="/cygdrive/d/a
>>> pache-ant/apache-ant-1.9.7"
>>> --with-jdk-home="C:\Program Files (x86)\Java\jdk1.8.0_73"
>>> --with-csc-path="C:\Windows\Microsoft.NET\Framework\v3.5"
>>> --with-dmake-url="http://sourceforge.net/projects/
>>> oooextras.mirror/files/dmake-4.12.tar.bz2" --with-epm-url="http://www.
>>> msweet.org/files/project2/epm-3.7-source.tar.gz" --disable-pch
>>> --disable-atl --disable-activex --without-junit
>>>
>>>
>>> On Wed, Sep 14, 2016 at 9:39 PM, John D'Orazio >> cappellaniauniroma3.org> wrote:
>>>
>>> So I've taken courage thanks also to the work done by Patricia Shanahan
 on building OpenOffice in Windows 7 and Windows 8.1. I'm using Windows
 10,
 and I've sorted through the first few obstacles and my build has now
 been
 running for 5-6 hours without any trouble. Until now that is. It just
 broke
 while building "guistdio.exe" in the desktop module. I'm not really
 seeing
 much information that can help me though, can any pick out what the
 trouble
 might be? Here is the last part of the build output:

 Compiling: desktop/test/deployment/active/active_native.cxx
 Making:test_deployment_active.lib
 Making:module definition file active_native.uno.def
 Making:itest_deployment_active_t1.lib
 lib -machine:IX86 @D:/cygwin/tmp/mktDdH6P
 Microsoft (R) Library Manager Version 9.00.30729.01
 Copyright (C) Microsoft Corporation.  All rights reserved.

 -out:../../../wntmsci12.pro/lib/itest_deployment_active_t1.lib
 -def:../../../wntmsci12.pro/misc/active_native.uno.def
Creating library ../../../wntmsci12.pro/lib/ite
 st_deployment_active_t1.lib and object ../../../wntmsci12.pro/lib/ite
 st_deployment_active_t1.exp
 Making:active_native.uno.dll
 Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
 Copyright (C) Microsoft Corporation.  All rights reserved.

 Microsoft (R) Incremental Linker Version 9.00.30729.01
 Copyright (C) Microsoft Corporation.  All rights reserved.

 /MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE
 -DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL -out:../../../
 wntmsci12.pro/bin/active_native.uno.dll

Re: building on Windows 10 breaks at guistdio.exe

2016-09-18 Thread Patricia Shanahan

Please excuse the delay responding - I put it aside hoping that someone 
with more knowledge would respond, and then got involved in other things.


One possibility is that solver/420/wntmsci12.pro/xml/ was partially 
built due to an earlier failure. I suggest deleting 
solver/420/wntmsci12.pro and trying again.


On 9/15/2016 5:52 AM, John D'Orazio wrote:

Patricia you are correct, after a few more attempts the desktop module did
build successfully. Now I'm up to the postprocess module, with this error:

Entering /cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents

dmake:  Error: -- `/cygdrive/d/source/aoo-trunk/main/solver/420/
wntmsci12.pro/xml/chartcontroller.component' not found, and can't be made

1 module(s):
postprocess
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents

When you have fixed the errors in that module you can resume the build by
running:

build --all:postprocess


Any ideas on this "chartcontroller.component"?


On Wed, Sep 14, 2016 at 11:58 PM, John D'Orazio <
john.dora...@cappellaniauniroma3.org> wrote:


If it can be of any use to understand better the problem, I'm using this
configuration:

SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"

./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
--with-midl-path="$SDK_PATH/bin" --with-directx-home="D:\
Microsoft_DirectX_SDK_June_2010" 
--with-ant-home="/cygdrive/d/apache-ant/apache-ant-1.9.7"
--with-jdk-home="C:\Program Files (x86)\Java\jdk1.8.0_73"
--with-csc-path="C:\Windows\Microsoft.NET\Framework\v3.5"
--with-dmake-url="http://sourceforge.net/projects/
oooextras.mirror/files/dmake-4.12.tar.bz2" --with-epm-url="http://www.
msweet.org/files/project2/epm-3.7-source.tar.gz" --disable-pch
--disable-atl --disable-activex --without-junit


On Wed, Sep 14, 2016 at 9:39 PM, John D'Orazio  wrote:


So I've taken courage thanks also to the work done by Patricia Shanahan
on building OpenOffice in Windows 7 and Windows 8.1. I'm using Windows 10,
and I've sorted through the first few obstacles and my build has now been
running for 5-6 hours without any trouble. Until now that is. It just broke
while building "guistdio.exe" in the desktop module. I'm not really seeing
much information that can help me though, can any pick out what the trouble
might be? Here is the last part of the build output:

Compiling: desktop/test/deployment/active/active_native.cxx
Making:test_deployment_active.lib
Making:module definition file active_native.uno.def
Making:itest_deployment_active_t1.lib
lib -machine:IX86 @D:/cygwin/tmp/mktDdH6P
Microsoft (R) Library Manager Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:../../../wntmsci12.pro/lib/itest_deployment_active_t1.lib
-def:../../../wntmsci12.pro/misc/active_native.uno.def
   Creating library ../../../wntmsci12.pro/lib/ite
st_deployment_active_t1.lib and object ../../../wntmsci12.pro/lib/ite
st_deployment_active_t1.exp
Making:active_native.uno.dll
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

/MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE
-DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL -out:../../../
wntmsci12.pro/bin/active_native.uno.dll -map:../../../wntmsci12.pro/mi
sc/active_native.uno.map ../../../wntmsci12.pro/lib/ite
st_deployment_active_t1.exp ../../../wntmsci12.pro/slo/active_native.obj
../../../wntmsci12.pro/slo/active_native.uno_version.obj icppuhelper.lib
icppu.lib isal.lib msvcrt.lib msvcprt.lib uwinapi.lib kernel32.lib
user32.lib oldnames.lib ../../../wntmsci12.pro/misc/active_native.uno.res
linking ../../../wntmsci12.pro/bin/active_native.uno.dll.manifest ...
Making:all_test_deployment_active.dpslo
mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/
/bin/rm -f ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
va.jar
/bin/rm -f -r ../../../wntmsci12.pro/misc/te
st_deployment_active/active_java.jar-zip
mkdir.exe ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
va.jar-zip
mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
va.jar-zip/META-INF \
../../../wntmsci12.pro/misc/test_deployment_active/active_ja
va.jar-zip/com/sun/star/comp/test/deployment/active_java
cp MANIFEST.MF ../../../wntmsci12.pro/misc/te
st_deployment_active/active_java.jar-zip/META-INF/
cp ../../../wntmsci12.pro/class/com/sun/star/comp/test/deployme
nt/active_java/Dispatch.class ../../../wntmsci12.pro/class/c
om/sun/star/comp/test/deployment/active_java/Provider.class ../../../
wntmsci12.pro/class/com/sun/star/comp/test/deployme
nt/active_java/Services.class \
../../../wntmsci12.pro/misc/test_deployment_active/active_ja

Re: building on Windows 10 breaks at guistdio.exe

2016-09-15 Thread John D'Orazio

Patricia you are correct, after a few more attempts the desktop module did
build successfully. Now I'm up to the postprocess module, with this error:

Entering /cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents

dmake:  Error: -- `/cygdrive/d/source/aoo-trunk/main/solver/420/
wntmsci12.pro/xml/chartcontroller.component' not found, and can't be made

1 module(s):
postprocess
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/d/source/aoo-trunk/main/postprocess/packcomponents

When you have fixed the errors in that module you can resume the build by
running:

build --all:postprocess


Any ideas on this "chartcontroller.component"?


On Wed, Sep 14, 2016 at 11:58 PM, John D'Orazio <
john.dora...@cappellaniauniroma3.org> wrote:

> If it can be of any use to understand better the problem, I'm using this
> configuration:
>
> SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"
>
> ./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
> --with-midl-path="$SDK_PATH/bin" --with-directx-home="D:\
> Microsoft_DirectX_SDK_June_2010" 
> --with-ant-home="/cygdrive/d/apache-ant/apache-ant-1.9.7"
> --with-jdk-home="C:\Program Files (x86)\Java\jdk1.8.0_73"
> --with-csc-path="C:\Windows\Microsoft.NET\Framework\v3.5"
> --with-dmake-url="http://sourceforge.net/projects/
> oooextras.mirror/files/dmake-4.12.tar.bz2" --with-epm-url="http://www.
> msweet.org/files/project2/epm-3.7-source.tar.gz" --disable-pch
> --disable-atl --disable-activex --without-junit
>
>
> On Wed, Sep 14, 2016 at 9:39 PM, John D'Orazio  cappellaniauniroma3.org> wrote:
>
>> So I've taken courage thanks also to the work done by Patricia Shanahan
>> on building OpenOffice in Windows 7 and Windows 8.1. I'm using Windows 10,
>> and I've sorted through the first few obstacles and my build has now been
>> running for 5-6 hours without any trouble. Until now that is. It just broke
>> while building "guistdio.exe" in the desktop module. I'm not really seeing
>> much information that can help me though, can any pick out what the trouble
>> might be? Here is the last part of the build output:
>>
>> Compiling: desktop/test/deployment/active/active_native.cxx
>> Making:test_deployment_active.lib
>> Making:module definition file active_native.uno.def
>> Making:itest_deployment_active_t1.lib
>> lib -machine:IX86 @D:/cygwin/tmp/mktDdH6P
>> Microsoft (R) Library Manager Version 9.00.30729.01
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> -out:../../../wntmsci12.pro/lib/itest_deployment_active_t1.lib
>> -def:../../../wntmsci12.pro/misc/active_native.uno.def
>>Creating library ../../../wntmsci12.pro/lib/ite
>> st_deployment_active_t1.lib and object ../../../wntmsci12.pro/lib/ite
>> st_deployment_active_t1.exp
>> Making:active_native.uno.dll
>> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Microsoft (R) Incremental Linker Version 9.00.30729.01
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> /MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE
>> -DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL -out:../../../
>> wntmsci12.pro/bin/active_native.uno.dll -map:../../../wntmsci12.pro/mi
>> sc/active_native.uno.map ../../../wntmsci12.pro/lib/ite
>> st_deployment_active_t1.exp ../../../wntmsci12.pro/slo/active_native.obj
>> ../../../wntmsci12.pro/slo/active_native.uno_version.obj icppuhelper.lib
>> icppu.lib isal.lib msvcrt.lib msvcprt.lib uwinapi.lib kernel32.lib
>> user32.lib oldnames.lib ../../../wntmsci12.pro/misc/active_native.uno.res
>> linking ../../../wntmsci12.pro/bin/active_native.uno.dll.manifest ...
>> Making:all_test_deployment_active.dpslo
>> mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/
>> /bin/rm -f ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
>> va.jar
>> /bin/rm -f -r ../../../wntmsci12.pro/misc/te
>> st_deployment_active/active_java.jar-zip
>> mkdir.exe ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
>> va.jar-zip
>> mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
>> va.jar-zip/META-INF \
>> ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
>> va.jar-zip/com/sun/star/comp/test/deployment/active_java
>> cp MANIFEST.MF ../../../wntmsci12.pro/misc/te
>> st_deployment_active/active_java.jar-zip/META-INF/
>> cp ../../../wntmsci12.pro/class/com/sun/star/comp/test/deployme
>> nt/active_java/Dispatch.class ../../../wntmsci12.pro/class/c
>> om/sun/star/comp/test/deployment/active_java/Provider.class ../../../
>> wntmsci12.pro/class/com/sun/star/comp/test/deployme
>> nt/active_java/Services.class \
>> ../../../wntmsci12.pro/misc/test_deployment_active/active_ja
>> va.jar-zip/com/sun/star/comp/test/deployment/active_java/
>> cd ../../../wntmsci12.pro/misc/test_deployment_active/active_java.jar-zip
>> && zip ../active_java.jar

Re: building on Windows 10 breaks at guistdio.exe

2016-09-14 Thread John D'Orazio

If it can be of any use to understand better the problem, I'm using this
configuration:

SDK_PATH="D:\Microsoft_SDKs\Windows\v7.0"

./configure --with-frame-home="$SDK_PATH" --with-psdk-home="$SDK_PATH"
--with-midl-path="$SDK_PATH/bin"
--with-directx-home="D:\Microsoft_DirectX_SDK_June_2010"
--with-ant-home="/cygdrive/d/apache-ant/apache-ant-1.9.7"
--with-jdk-home="C:\Program Files (x86)\Java\jdk1.8.0_73"
--with-csc-path="C:\Windows\Microsoft.NET\Framework\v3.5" --with-dmake-url="
http://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2;
--with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz;
--disable-pch --disable-atl --disable-activex --without-junit


On Wed, Sep 14, 2016 at 9:39 PM, John D'Orazio <
john.dora...@cappellaniauniroma3.org> wrote:

> So I've taken courage thanks also to the work done by Patricia Shanahan on
> building OpenOffice in Windows 7 and Windows 8.1. I'm using Windows 10, and
> I've sorted through the first few obstacles and my build has now been
> running for 5-6 hours without any trouble. Until now that is. It just broke
> while building "guistdio.exe" in the desktop module. I'm not really seeing
> much information that can help me though, can any pick out what the trouble
> might be? Here is the last part of the build output:
>
> Compiling: desktop/test/deployment/active/active_native.cxx
> Making:test_deployment_active.lib
> Making:module definition file active_native.uno.def
> Making:itest_deployment_active_t1.lib
> lib -machine:IX86 @D:/cygwin/tmp/mktDdH6P
> Microsoft (R) Library Manager Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> -out:../../../wntmsci12.pro/lib/itest_deployment_active_t1.lib
> -def:../../../wntmsci12.pro/misc/active_native.uno.def
>Creating library ../../../wntmsci12.pro/lib/
> itest_deployment_active_t1.lib and object ../../../wntmsci12.pro/lib/
> itest_deployment_active_t1.exp
> Making:active_native.uno.dll
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Microsoft (R) Incremental Linker Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> /MAP /OPT:NOREF -safeseh -nxcompat -dynamicbase -NODEFAULTLIB -RELEASE
> -DEBUG -INCREMENTAL:NO /SUBSYSTEM:CONSOLE /DLL -out:../../../
> wntmsci12.pro/bin/active_native.uno.dll -map:../../../wntmsci12.pro/
> misc/active_native.uno.map ../../../wntmsci12.pro/lib/
> itest_deployment_active_t1.exp ../../../wntmsci12.pro/slo/
> active_native.obj ../../../wntmsci12.pro/slo/active_native.uno_version.obj
> icppuhelper.lib icppu.lib isal.lib msvcrt.lib msvcprt.lib uwinapi.lib
> kernel32.lib user32.lib oldnames.lib ../../../wntmsci12.pro/misc/
> active_native.uno.res
> linking ../../../wntmsci12.pro/bin/active_native.uno.dll.manifest ...
> Making:all_test_deployment_active.dpslo
> mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/
> /bin/rm -f ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar
> /bin/rm -f -r ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip
> mkdir.exe ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip
> mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip/META-INF \
> ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip/com/sun/star/comp/test/deployment/active_java
> cp MANIFEST.MF ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip/META-INF/
> cp ../../../wntmsci12.pro/class/com/sun/star/comp/test/
> deployment/active_java/Dispatch.class ../../../wntmsci12.pro/class/
> com/sun/star/comp/test/deployment/active_java/Provider.class ../../../
> wntmsci12.pro/class/com/sun/star/comp/test/deployment/active_java/
> Services.class \
> ../../../wntmsci12.pro/misc/test_deployment_active/active_
> java.jar-zip/com/sun/star/comp/test/deployment/active_java/
> cd ../../../wntmsci12.pro/misc/test_deployment_active/active_java.jar-zip
> && zip ../active_java.jar \
> META-INF/MANIFEST.MF com/sun/star/comp/test/
> deployment/active_java/Dispatch.class com/sun/star/comp/test/
> deployment/active_java/Provider.class com/sun/star/comp/test/
> deployment/active_java/Services.class
>   adding: META-INF/MANIFEST.MF (deflated 9%)
>   adding: com/sun/star/comp/test/deployment/active_java/Dispatch.class
> (deflated 54%)
>   adding: com/sun/star/comp/test/deployment/active_java/Provider.class
> (deflated 52%)
>   adding: com/sun/star/comp/test/deployment/active_java/Services.class
> (deflated 54%)
> /bin/rm -f ../../../wntmsci12.pro/misc/active.oxt
> /bin/rm -f -r ../../../wntmsci12.pro/misc/test_deployment_active/active.
> oxt-zip
> mkdir.exe ../../../wntmsci12.pro/misc/test_deployment_active/active.
> oxt-zip
> mkdir.exe -p ../../../wntmsci12.pro/misc/test_deployment_active/active.
> oxt-zip/META-INF
> sed -e

Re: building on Windows 10 breaks at guistdio.exe

2016-09-14 Thread Patricia Shanahan

I've never seen this failure before. The only suggestion I can make is 
to retry. That sometimes fixes failed builds.


On 9/14/2016 12:39 PM, John D'Orazio wrote:
...

dmake:  '../../../wntmsci12.pro/bin/guistdio.exe' removed.

1 module(s):
desktop
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/d/source/aoo-trunk/main/desktop/win32/source/guistdio

When you have fixed the errors in that module you can resume the build by
running:

build --all:desktop

Do I perhaps need to enable a verbose output to have more information to go
on?



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-07-01 Thread Patricia Shanahan

Could this patch also be modified to apply to 4.1.2? It may be the issue 
preventing me from doing Windows builds of that release.


On 2/10/2016 3:57 PM, Damjan Jovanovic wrote:

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:


I have already done some of this. The key difference between failing and
non-failing is whether layoutex is built early or later in the build. See
the attached files for sample build outputs.

I believe layoutex has a dependency on icuin.lib that is not properly
declared in the makefile etc., allowing layoutex to be built too soon. If
so, the best fix would be to declare the dependency, but I don't know
enough about the dmake and configuration stuff to make that change without
some study first.

Patricia


On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:


The icu module has a complicated build with scripts generating
makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
 my $pid = shift;
 # A malicious hack for mysterious windows problems - try 2 times
 # to run dmake in the same directory if errors occurs
 my $child_nick = $processes_hash{$pid};
 $running_children{$folders_hashes{$child_nick}}--;
 delete $processes_hash{$pid};
 start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

My next step is to try to get rid of the intermittent failure of the icu

build. It seems to be the one thing standing between me a repeatable
unattended build. If you know anything about its cause, please let me
know.

Here is a typical failure output:

Generating Code...
 link.exe @C:\cygwin32\tmp\nm2E74.tmp
Creating library .\..\..\lib\icule.lib and object
.\..\..\lib\icule.exp
 if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
 copy ".\LEFontInstance.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEGlyphFilter.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEGlyphStorage.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEInsertionList.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LELanguages.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEScripts.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LESwaps.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LETypes.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LayoutEngine.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\loengine.h" ..\..\include\layout
 1 file(s) copied.
 cd "..\allinone"
 cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
\misc\build\icu\source\allinone\..\layoutex"
 C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

 if not exist ".\Release/" mkdir ".\Release"
 rc.exe

RE: Building on Windows

2016-02-14 Thread Dennis E. Hamilton

I couldn't tell from your updated instruction page what compiler was used. 

Does your build use a compiler that is in the Windows 7 SDK, or another 
compiler, such as an Express edition?

And thank you and Damjan for all of the attention it took to get this working.

 - Dennis

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Sunday, February 14, 2016 17:29
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
> On 2/14/2016 1:34 PM, Patricia Shanahan wrote:
> >
> >
> > On 2/14/2016 1:32 PM, Patricia Shanahan wrote:
> >> On 2/5/2016 6:55 AM, Damjan Jovanovic wrote:
> >>> On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel
> >>> <rb.hensc...@t-online.de>
> >>> wrote:
> >>>
> >>>> Hi Patricia,
> >>>>
> >>>> Patricia Shanahan schrieb:
> >>>>
> >>>>> My build finished!
> >>>>>
> >>>>> The next problem is to run it. I have hit two problems, one minor.
> The
> >>>>> minor problem is that
> >>>>>
> >>>>>
> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_b
> y_step#Windows_7
> >>>>>
> >>>>>
> >>>>> has incorrect paths using "OpenOffice" rather than
> >>>>> "Apache_OpenOffice".
> >>>>>
[ ... ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-14 Thread Patricia Shanahan


On 2/14/2016 1:34 PM, Patricia Shanahan wrote:



On 2/14/2016 1:32 PM, Patricia Shanahan wrote:

On 2/5/2016 6:55 AM, Damjan Jovanovic wrote:

On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel

wrote:


Hi Patricia,

Patricia Shanahan schrieb:


My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7


has incorrect paths using "OpenOffice" rather than
"Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.



You are right, there is only the folder en-US (or your preferred
language)
in instset-native/wntmsci12/Apache_OpenOffice. You can use the setup
or the
msi-file to make an administrative installation.

When you have got the installation, then when you made changes, then
it is
enough to drop those files from solver/420/wntmsci12/bin into your
installation, which have changed. Most times that are only a few dlls.

LibreOffice generates a folder with an immediately executable
soffice.exe.
So there might exist a configure switch for that in Apache OpenOffice
too,
but I don't know.



If you mean --with-package-format="installed" to ./configure (IIRC the
default is archive, but you can --with-package-format="archive
installed"
to get both) then yes we do have it.


I tried adding --with-package-format="archive installed" to my configure
parameters, and still don't get a .zip file.


Scrub that. I am not 100% sure I re-ran configure before building :-(


It works fine if I configure before building. I now have both a zip 
file, for copying to other systems, and a ready-to-run version.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-14 Thread Patricia Shanahan


On 2/5/2016 6:55 AM, Damjan Jovanovic wrote:

On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel 
wrote:


Hi Patricia,

Patricia Shanahan schrieb:


My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.



You are right, there is only the folder en-US (or your preferred language)
in instset-native/wntmsci12/Apache_OpenOffice. You can use the setup or the
msi-file to make an administrative installation.

When you have got the installation, then when you made changes, then it is
enough to drop those files from solver/420/wntmsci12/bin into your
installation, which have changed. Most times that are only a few dlls.

LibreOffice generates a folder with an immediately executable soffice.exe.
So there might exist a configure switch for that in Apache OpenOffice too,
but I don't know.



If you mean --with-package-format="installed" to ./configure (IIRC the
default is archive, but you can --with-package-format="archive installed"
to get both) then yes we do have it.


I tried adding --with-package-format="archive installed" to my configure 
parameters, and still don't get a .zip file.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-14 Thread Patricia Shanahan




On 2/14/2016 1:32 PM, Patricia Shanahan wrote:

On 2/5/2016 6:55 AM, Damjan Jovanovic wrote:

On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel 
wrote:


Hi Patricia,

Patricia Shanahan schrieb:


My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7

has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.



You are right, there is only the folder en-US (or your preferred
language)
in instset-native/wntmsci12/Apache_OpenOffice. You can use the setup
or the
msi-file to make an administrative installation.

When you have got the installation, then when you made changes, then
it is
enough to drop those files from solver/420/wntmsci12/bin into your
installation, which have changed. Most times that are only a few dlls.

LibreOffice generates a folder with an immediately executable
soffice.exe.
So there might exist a configure switch for that in Apache OpenOffice
too,
but I don't know.



If you mean --with-package-format="installed" to ./configure (IIRC the
default is archive, but you can --with-package-format="archive installed"
to get both) then yes we do have it.


I tried adding --with-package-format="archive installed" to my configure
parameters, and still don't get a .zip file.


Scrub that. I am not 100% sure I re-ran configure before building :-(

Patricia


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-11 Thread Damjan Jovanovic

Thank you. Also recompiled icu 200 times successfully, so we can be
pretty sure that patch is correct.

I've made a bug for this issue
(https://bz.apache.org/ooo/show_bug.cgi?id=126840) and committed the
patch in r1729921:

#i126840# - Windows/MSVC build often fails in main/icu

The build script (used only on MSVC, not MingW or other OSes) for icu
generates nmake makefiles for the build using icu's
source/allinone/allinone.sln, in which layoutex doesn't list a dependency
on i18n, despite linking to icuin.lib from i18n, which sporadically causes
the icu build to fail. This is really an upstream bug, however upstream
doesn't build using allinone.sln so we are affected more.

This patch declares the missing dependecy, and makes icu build reliably.

Patch by: me
Tested by: pats

On Thu, Feb 11, 2016 at 7:33 PM, Patricia Shanahan  wrote:
> Your patch works for me.
>
> On 2/10/2016 3:57 PM, Damjan Jovanovic wrote:
>>
>> icu supports building on Cygwin using Cygwin's make, but for some bizarre
>> reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
>> script and even completely bypassing ./configure (makefile.mk has
>> CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
>> ..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
>> that up, nor does the nmake build parallelize at all, which is why icu
>> wastes 5 minutes building while using only a single thread, so you have to
>> wonder why it was done that way.
>>
>> Building with mingw or building on any other platform does use ./configure
>> and GNU make instead, which explains why we only see this bug with MSVC.
>>
>> Anyway I think I've hacked icu into working. In allinone.sln I've made
>> layoutex project depend on the i18n project containing icuin.lib, and the
>> Perl script should convert that dependency into the makefiles it creates.
>> So far icu has been rebuilt 10 times with this patch (attached),
>> succeeding
>> every time, so please test it and see if it works for you as well.
>>
>> Damjan
>>
>> On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:
>>
>>> I have already done some of this. The key difference between failing and
>>> non-failing is whether layoutex is built early or later in the build. See
>>> the attached files for sample build outputs.
>>>
>>> I believe layoutex has a dependency on icuin.lib that is not properly
>>> declared in the makefile etc., allowing layoutex to be built too soon. If
>>> so, the best fix would be to declare the dependency, but I don't know
>>> enough about the dmake and configuration stuff to make that change
>>> without
>>> some study first.
>>>
>>> Patricia
>>>
>>>
>>> On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:
>>>
 The icu module has a complicated build with scripts generating
 makefiles...

 I am not sure what approach to even take debugging this, but some ideas
 might be:
 * make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
 copy of one that doesn't, then diff the files to see what's different
 * compare build logs with it working and not working, to see what steps
 differ (eg. build order of some files might be different)
 * try and follow the makefile to understand the problem analytically; my
 first try didn't get me far
 * give up completely, and just hack it. Make a loop in build.pl that
 just
 keeps cleaning and rebuilding the module. If it builds 50% of the time,
 with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1
 in
 2^20 will fail, etc. Something like this might already have been tried
 in
 the past, as build.pl contains the following code which is only run on
 Windows:

 sub give_second_chance {
   my $pid = shift;
   # A malicious hack for mysterious windows problems - try 2 times
   # to run dmake in the same directory if errors occurs
   my $child_nick = $processes_hash{$pid};
   $running_children{$folders_hashes{$child_nick}}--;
   delete $processes_hash{$pid};
   start_child($child_nick, $folders_hashes{$child_nick});
 };

 On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

 My next step is to try to get rid of the intermittent failure of the icu
>
> build. It seems to be the one thing standing between me a repeatable
> unattended build. If you know anything about its cause, please let me
> know.
>
> Here is a typical failure output:
>
> Generating Code...
>   link.exe @C:\cygwin32\tmp\nm2E74.tmp
>  Creating library .\..\..\lib\icule.lib and object
> .\..\..\lib\icule.exp
>   if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
> ..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
>   copy ".\LEFontInstance.h" ..\..\include\layout
>   1 file(s) copied.
>

Re: Building on Windows

2016-02-11 Thread Patricia Shanahan

I have made changes to 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step 
to record what I learned during this process.


It would be helpful if someone with a Windows machine could attempt a 
build using the latest version of those instructions, to test them.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-11 Thread Patricia Shanahan


Your patch works for me.

On 2/10/2016 3:57 PM, Damjan Jovanovic wrote:

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:


I have already done some of this. The key difference between failing and
non-failing is whether layoutex is built early or later in the build. See
the attached files for sample build outputs.

I believe layoutex has a dependency on icuin.lib that is not properly
declared in the makefile etc., allowing layoutex to be built too soon. If
so, the best fix would be to declare the dependency, but I don't know
enough about the dmake and configuration stuff to make that change without
some study first.

Patricia


On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:


The icu module has a complicated build with scripts generating
makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
  my $pid = shift;
  # A malicious hack for mysterious windows problems - try 2 times
  # to run dmake in the same directory if errors occurs
  my $child_nick = $processes_hash{$pid};
  $running_children{$folders_hashes{$child_nick}}--;
  delete $processes_hash{$pid};
  start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

My next step is to try to get rid of the intermittent failure of the icu

build. It seems to be the one thing standing between me a repeatable
unattended build. If you know anything about its cause, please let me
know.

Here is a typical failure output:

Generating Code...
  link.exe @C:\cygwin32\tmp\nm2E74.tmp
 Creating library .\..\..\lib\icule.lib and object
.\..\..\lib\icule.exp
  if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
  copy ".\LEFontInstance.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphFilter.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphStorage.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEInsertionList.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LELanguages.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEScripts.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LESwaps.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LETypes.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LayoutEngine.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\loengine.h" ..\..\include\layout
  1 file(s) copied.
  cd "..\allinone"
  cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
\misc\build\icu\source\allinone\..\layoutex"
  C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

  if not exist ".\Release/" mkdir ".\Release"
  rc.exe /l 0x409 /fo".\Release\layoutex.res" /i "..\common" /d
"NDEBUG"

Re: Building on Windows

2016-02-10 Thread Patricia Shanahan


I have experienced a major step backwards. My build attempts all fail:

==
$ build --All
build -- version: 275224


=
Building module instsetoo_native
=

Entering 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages


Usage:
dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value 
...]

  [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages

==

This persists despite a clean checkout and configure.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-10 Thread Patricia Shanahan

Thanks. Silly typo, when I've typed "build --all" dozens of times over 
the last couple of weeks.


On 2/10/2016 2:22 PM, Damjan Jovanovic wrote:

I can reproduce that. The "--All" needs to be in lowercase, ie. "build --all".

On Wed, Feb 10, 2016 at 11:20 PM, Patricia Shanahan  wrote:

I have experienced a major step backwards. My build attempts all fail:

==
$ build --All
build -- version: 275224


=
Building module instsetoo_native
=

Entering
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages

Usage:
dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value
...]
   [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
==

This persists despite a clean checkout and configure.




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-10 Thread Damjan Jovanovic

I can reproduce that. The "--All" needs to be in lowercase, ie. "build --all".

On Wed, Feb 10, 2016 at 11:20 PM, Patricia Shanahan  wrote:
> I have experienced a major step backwards. My build attempts all fail:
>
> ==
> $ build --All
> build -- version: 275224
>
>
> =
> Building module instsetoo_native
> =
>
> Entering
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
>
> Usage:
> dmake [-P#] [-{f|K} file] [-{w|W} target ...] [macro[!][[*][+][:]]=value
> ...]
>   [-v[cdfimrtw]] [-m[trae]] [-ABcdeEghiknpqrsStTuVxX] [target ...]
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
> ==
>
> This persists despite a clean checkout and configure.
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-10 Thread Patricia Shanahan


Thanks. I'll take it for a test drive tomorrow.

On 2/10/2016 3:57 PM, Damjan Jovanovic wrote:

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:


I have already done some of this. The key difference between failing and
non-failing is whether layoutex is built early or later in the build. See
the attached files for sample build outputs.

I believe layoutex has a dependency on icuin.lib that is not properly
declared in the makefile etc., allowing layoutex to be built too soon. If
so, the best fix would be to declare the dependency, but I don't know
enough about the dmake and configuration stuff to make that change without
some study first.

Patricia


On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:


The icu module has a complicated build with scripts generating
makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
  my $pid = shift;
  # A malicious hack for mysterious windows problems - try 2 times
  # to run dmake in the same directory if errors occurs
  my $child_nick = $processes_hash{$pid};
  $running_children{$folders_hashes{$child_nick}}--;
  delete $processes_hash{$pid};
  start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

My next step is to try to get rid of the intermittent failure of the icu

build. It seems to be the one thing standing between me a repeatable
unattended build. If you know anything about its cause, please let me
know.

Here is a typical failure output:

Generating Code...
  link.exe @C:\cygwin32\tmp\nm2E74.tmp
 Creating library .\..\..\lib\icule.lib and object
.\..\..\lib\icule.exp
  if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
  copy ".\LEFontInstance.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphFilter.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEGlyphStorage.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEInsertionList.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LELanguages.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LEScripts.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LESwaps.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LETypes.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\LayoutEngine.h" ..\..\include\layout
  1 file(s) copied.
  copy ".\loengine.h" ..\..\include\layout
  1 file(s) copied.
  cd "..\allinone"
  cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
\misc\build\icu\source\allinone\..\layoutex"
  C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

  if not exist ".\Release/" mkdir ".\Release"
  rc.exe /l 0x409 /fo".\Release\layoutex.res" /i

Re: Building on Windows

2016-02-10 Thread Damjan Jovanovic

icu supports building on Cygwin using Cygwin's make, but for some bizarre
reason AOO builds it with MSVC's nmake using makefiles generated by a Perl
script and even completely bypassing ./configure (makefile.mk has
CONFIGURE_ACTION+= $(PERL) ..$/..$/..$/..$/..$/createmak.pl
..$/..$/..$/..$/..$/createmak.cfg .). It could not have been easy to set
that up, nor does the nmake build parallelize at all, which is why icu
wastes 5 minutes building while using only a single thread, so you have to
wonder why it was done that way.

Building with mingw or building on any other platform does use ./configure
and GNU make instead, which explains why we only see this bug with MSVC.

Anyway I think I've hacked icu into working. In allinone.sln I've made
layoutex project depend on the i18n project containing icuin.lib, and the
Perl script should convert that dependency into the makefiles it creates.
So far icu has been rebuilt 10 times with this patch (attached), succeeding
every time, so please test it and see if it works for you as well.

Damjan

On Tue, Feb 9, 2016 at 7:51 PM, Patricia Shanahan  wrote:

> I have already done some of this. The key difference between failing and
> non-failing is whether layoutex is built early or later in the build. See
> the attached files for sample build outputs.
>
> I believe layoutex has a dependency on icuin.lib that is not properly
> declared in the makefile etc., allowing layoutex to be built too soon. If
> so, the best fix would be to declare the dependency, but I don't know
> enough about the dmake and configuration stuff to make that change without
> some study first.
>
> Patricia
>
>
> On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:
>
>> The icu module has a complicated build with scripts generating
>> makefiles...
>>
>> I am not sure what approach to even take debugging this, but some ideas
>> might be:
>> * make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
>> copy of one that doesn't, then diff the files to see what's different
>> * compare build logs with it working and not working, to see what steps
>> differ (eg. build order of some files might be different)
>> * try and follow the makefile to understand the problem analytically; my
>> first try didn't get me far
>> * give up completely, and just hack it. Make a loop in build.pl that just
>> keeps cleaning and rebuilding the module. If it builds 50% of the time,
>> with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
>> 2^20 will fail, etc. Something like this might already have been tried in
>> the past, as build.pl contains the following code which is only run on
>> Windows:
>>
>> sub give_second_chance {
>>  my $pid = shift;
>>  # A malicious hack for mysterious windows problems - try 2 times
>>  # to run dmake in the same directory if errors occurs
>>  my $child_nick = $processes_hash{$pid};
>>  $running_children{$folders_hashes{$child_nick}}--;
>>  delete $processes_hash{$pid};
>>  start_child($child_nick, $folders_hashes{$child_nick});
>> };
>>
>>
>> On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:
>>
>> My next step is to try to get rid of the intermittent failure of the icu
>>> build. It seems to be the one thing standing between me a repeatable
>>> unattended build. If you know anything about its cause, please let me
>>> know.
>>>
>>> Here is a typical failure output:
>>>
>>> Generating Code...
>>>  link.exe @C:\cygwin32\tmp\nm2E74.tmp
>>> Creating library .\..\..\lib\icule.lib and object
>>> .\..\..\lib\icule.exp
>>>  if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
>>> ..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
>>>  copy ".\LEFontInstance.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEGlyphFilter.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEGlyphStorage.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEInsertionList.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LELanguages.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LEScripts.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LESwaps.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LETypes.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\LayoutEngine.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  copy ".\loengine.h" ..\..\include\layout
>>>  1 file(s) copied.
>>>  cd "..\allinone"
>>>  cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
>>> \misc\build\icu\source\allinone\..\layoutex"
>>>  C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
>>> layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"
>>>
>>> Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
>>> Copyright (C) Microsoft Corporation.

Re: Building on Windows

2016-02-09 Thread Damjan Jovanovic

The icu module has a complicated build with scripts generating makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
my $pid = shift;
# A malicious hack for mysterious windows problems - try 2 times
# to run dmake in the same directory if errors occurs
my $child_nick = $processes_hash{$pid};
$running_children{$folders_hashes{$child_nick}}--;
delete $processes_hash{$pid};
start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:

> My next step is to try to get rid of the intermittent failure of the icu
> build. It seems to be the one thing standing between me a repeatable
> unattended build. If you know anything about its cause, please let me know.
>
> Here is a typical failure output:
>
> Generating Code...
> link.exe @C:\cygwin32\tmp\nm2E74.tmp
>Creating library .\..\..\lib\icule.lib and object .\..\..\lib\icule.exp
> if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
> ..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
> copy ".\LEFontInstance.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LEGlyphFilter.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LEGlyphStorage.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LEInsertionList.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LELanguages.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LEScripts.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LESwaps.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LETypes.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\LayoutEngine.h" ..\..\include\layout
> 1 file(s) copied.
> copy ".\loengine.h" ..\..\include\layout
> 1 file(s) copied.
> cd "..\allinone"
> cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
> \misc\build\icu\source\allinone\..\layoutex"
> C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
> layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"
>
> Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> if not exist ".\Release/" mkdir ".\Release"
> rc.exe /l 0x409 /fo".\Release\layoutex.res" /i "..\common" /d
> "NDEBUG" .\layoutex.rc
> Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
> return code '0x2'
> Stop.
> dmake:  Error code 2, while making './
> wntmsci12.pro/misc/build/so_built_so_icu'
>
> 1 module(s):
> icu
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/icu
>
> When you have fixed the errors in that module you can resume the build by
> running:
>
> build --all:icu
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Building on Windows

2016-02-09 Thread Patricia Shanahan

I have already done some of this. The key difference between failing and 
non-failing is whether layoutex is built early or later in the build. 
See the attached files for sample build outputs.


I believe layoutex has a dependency on icuin.lib that is not properly 
declared in the makefile etc., allowing layoutex to be built too soon. 
If so, the best fix would be to declare the dependency, but I don't know 
enough about the dmake and configuration stuff to make that change 
without some study first.


Patricia

On 2/9/2016 9:40 AM, Damjan Jovanovic wrote:

The icu module has a complicated build with scripts generating makefiles...

I am not sure what approach to even take debugging this, but some ideas
might be:
* make a copy of a main/icu[/wntmsci12.pro] directory that builds and a
copy of one that doesn't, then diff the files to see what's different
* compare build logs with it working and not working, to see what steps
differ (eg. build order of some files might be different)
* try and follow the makefile to understand the problem analytically; my
first try didn't get me far
* give up completely, and just hack it. Make a loop in build.pl that just
keeps cleaning and rebuilding the module. If it builds 50% of the time,
with 10 retries only 1 in 1024 builds will fail, with 20 retries only 1 in
2^20 will fail, etc. Something like this might already have been tried in
the past, as build.pl contains the following code which is only run on
Windows:

sub give_second_chance {
 my $pid = shift;
 # A malicious hack for mysterious windows problems - try 2 times
 # to run dmake in the same directory if errors occurs
 my $child_nick = $processes_hash{$pid};
 $running_children{$folders_hashes{$child_nick}}--;
 delete $processes_hash{$pid};
 start_child($child_nick, $folders_hashes{$child_nick});
};


On Sun, Feb 7, 2016 at 1:42 AM, Patricia Shanahan  wrote:


My next step is to try to get rid of the intermittent failure of the icu
build. It seems to be the one thing standing between me a repeatable
unattended build. If you know anything about its cause, please let me know.

Here is a typical failure output:

Generating Code...
 link.exe @C:\cygwin32\tmp\nm2E74.tmp
Creating library .\..\..\lib\icule.lib and object .\..\..\lib\icule.exp
 if exist ..\..\bin\icule40.dll.manifest mt.exe -manifest
..\..\bin\icule40.dll.manifest -outputresource:..\..\bin\icule40.dll;2
 copy ".\LEFontInstance.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEGlyphFilter.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEGlyphStorage.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEInsertionList.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LELanguages.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LEScripts.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LESwaps.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LETypes.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\LayoutEngine.h" ..\..\include\layout
 1 file(s) copied.
 copy ".\loengine.h" ..\..\include\layout
 1 file(s) copied.
 cd "..\allinone"
 cd "C:\OpenOfficeDev\Trunk\main\icu\wntmsci12.pro
\misc\build\icu\source\allinone\..\layoutex"
 C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe /   /F
layoutex.mak EXCEPTIONSWITCH="-EHa -Zc:wchar_t-"

Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation.  All rights reserved.

 if not exist ".\Release/" mkdir ".\Release"
 rc.exe /l 0x409 /fo".\Release\layoutex.res" /i "..\common" /d
"NDEBUG" .\layoutex.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'

1 module(s):
 icu
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/icu

When you have fixed the errors in that module you can resume the build by
running:

 build --all:icu


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




build -- version: 275224


=
Building module icu
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/icu

mkout -- version: 1.8
if [ -d ./wntmsci12.pro/misc/build/icu ] ; then echo "moving" && mv 
./wntmsci12.pro/misc/build/icu ./wntmsci12.pro/misc/build/icu_removeme ; fi
make writeable...
patching file icu/source/config/mh-bsd-gcc
patching file

Re: Building on Windows

2016-02-05 Thread Regina Henschel


Hi Patricia,

Patricia Shanahan schrieb:

My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.


You are right, there is only the folder en-US (or your preferred 
language) in instset-native/wntmsci12/Apache_OpenOffice. You can use the 
setup or the msi-file to make an administrative installation.


When you have got the installation, then when you made changes, then it 
is enough to drop those files from solver/420/wntmsci12/bin into your 
installation, which have changed. Most times that are only a few dlls.


LibreOffice generates a folder with an immediately executable 
soffice.exe. So there might exist a configure switch for that in Apache 
OpenOffice too, but I don't know.


Kind regards
Regina






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-05 Thread Damjan Jovanovic

On Fri, Feb 5, 2016 at 4:52 PM, Regina Henschel 
wrote:

> Hi Patricia,
>
> Patricia Shanahan schrieb:
>
>> My build finished!
>>
>> The next problem is to run it. I have hit two problems, one minor. The
>> minor problem is that
>>
>> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
>> has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".
>>
>> The more serious problem is that there does not seem to be a zip file
>> for running without actually installing.
>>
>
> You are right, there is only the folder en-US (or your preferred language)
> in instset-native/wntmsci12/Apache_OpenOffice. You can use the setup or the
> msi-file to make an administrative installation.
>
> When you have got the installation, then when you made changes, then it is
> enough to drop those files from solver/420/wntmsci12/bin into your
> installation, which have changed. Most times that are only a few dlls.
>
> LibreOffice generates a folder with an immediately executable soffice.exe.
> So there might exist a configure switch for that in Apache OpenOffice too,
> but I don't know.
>
>
If you mean --with-package-format="installed" to ./configure (IIRC the
default is archive, but you can --with-package-format="archive installed"
to get both) then yes we do have it.


> Kind regards
> Regina
>
>
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Building on Windows

2016-02-05 Thread Patricia Shanahan

My build finished!

The next problem is to run it. I have hit two problems, one minor. The
minor problem is that
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7
has incorrect paths using "OpenOffice" rather than "Apache_OpenOffice".

The more serious problem is that there does not seem to be a zip file
for running without actually installing.

Patricia

The last few messages were:

**
... creating download installation set ...
**
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
Redundant argument in sprintf at
C:/OpenOfficeDev/Trunk/main/solenv/bin/modules/installer/logger.pm line 192.
... created NSIS file
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/nsis/en-US/downloadtemplate.nsi
...

... starting C:/PROGRA~2/NSIS/makensis.exe ...
... checking log file
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/logging/en-US/log_AOO420_en-US.log

***
Successful packaging process!
***
copying log file to
C:/OpenOfficeDev/Trunk/main/instsetoo_native/wntmsci12.pro/Apache_OpenOffice_SDK/msi/install/log/log_AOO420_en-US.log

stopping log at Fri Feb 5 04:53:25 2016

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-04 Thread Regina Henschel


Hi Patricia,

I had sometimes curious build breaks because of parallelism and virus 
scan. So please try to make a build without any parallelism and disable 
virus scan. Additional benefit: without parallelism, the log tells you 
the actual module order.


Kind regards
Regina

Patricia Shanahan schrieb:

Yes, there is certainly stuff to investigate. My latest failure is:

/usr/bin/cp: missing destination file operand after
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib'

Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
for target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib]
Error 1
dmake:  Error code 2, while making 'all'

1 module(s):
 xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj

When you have fixed the errors in that module you can resume the build
by running:

 build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:

main/oox/prj/build.lst already lists xmlscript as a dependency, so
"build"
should have built it before starting to build oox. Something must be very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:


Yes, thanks. At least, it gets past oox.

So one trick for a missing file is to explicitly build and deliver in
the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate
anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:


That is strange. Does it work if you first do "build" and "deliver" in
main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan  wrote:

I am now getting to:


Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
error C1083: Cannot open include file:
'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../
wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
  oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was able to

get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:

==

c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) :
fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch

'
unexpected precompiled header error, simply rerunning the compiler
might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126:
recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
   svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the
build
by running:

   build --all:svl
==


The build system knows the failure is potentially retriable. It
tells me
exactly what to type to do the retry. WHY can't it just retry itself,
without needing my fingers on the keyboard?



On 2/2/2016 8:10 AM, Patricia Shanahan wrote:

OpenGrok looks and sounds like something I should learn about.


I think my next step is to look into the state of python. Matters
may
have been complicated because I did a "dmake clean" after
changing my
configure parameters to use a 32 bit JDK, before continuing the
steps
from configure on.

There may be a pause - I have some non-programming stuff to do today
and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle
things
out for myself first.

On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:

OpenGrok[1] tells me the pyversion.mk file is in main/python;
through

building it would get delivered to main/solver/... and found by
pyuno.
Did
python not build before pyuno did? pyuno/prj/build.lst lists a
dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools
PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's

Re: Building on Windows

On Thu, Feb 4, 2016 at 11:47 PM, Patricia Shanahan  wrote:

> On 2/4/2016 12:40 PM, Regina Henschel wrote:
>
>> Hi Patricia,
>>
>> Patricia Shanahan schrieb:
>>
>>> I think maybe I need to clean up and start again. What is the best way
>>> to clean, short of doing a fresh checkout?
>>>
>>
>> I remove the output-tree manually
>>
>> Starting in main:
>> find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf
>>
>> In addition delete wntmsci12* from folder solver.
>>
>> In addition delete wntmsci12* from folders in ext_libraries
>>
>
> Thanks.
>
> My next question is the best way to control the C compiler options. I want
> to get rid of precompiled headers.
>
>
You're using precompiled headers because you passed --enable-pch to
./configure.

Re: Building on Windows


On 2/4/2016 12:40 PM, Regina Henschel wrote:

Hi Patricia,

Patricia Shanahan schrieb:

I think maybe I need to clean up and start again. What is the best way
to clean, short of doing a fresh checkout?


I remove the output-tree manually

Starting in main:
find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf

In addition delete wntmsci12* from folder solver.

In addition delete wntmsci12* from folders in ext_libraries


Thanks.

My next question is the best way to control the C compiler options. I 
want to get rid of precompiled headers.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Building on Windows

2016-02-04 Thread Dennis E. Hamilton

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Thursday, February 4, 2016 13:48
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
> On 2/4/2016 12:40 PM, Regina Henschel wrote:
> > Hi Patricia,
> >
> > Patricia Shanahan schrieb:
> >> I think maybe I need to clean up and start again. What is the best
> way
> >> to clean, short of doing a fresh checkout?
> >
> > I remove the output-tree manually
> >
> > Starting in main:
> > find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf
> >
> > In addition delete wntmsci12* from folder solver.
> >
> > In addition delete wntmsci12* from folders in ext_libraries
> 
> Thanks.
> 
> My next question is the best way to control the C compiler options. I
> want to get rid of precompiled headers.
> 
[orcmid] 

+1 on eliminating precompiled headers.  They are an anachronism.

If you can specify the command-line options, here's the scoop.

Using the VC++ command line compiler, you can get most of the options with 
command

 cl.exe -? | more

Top-of-head recommendation:

   Do not have option /Fp to name precompiled header file
   Do not have option /Yu for using precompiled headers
   Do not have option /Yc for creating precompiled headers
   Ensure that "stdafx.cpp" is not a parameter 
   Ensure none of these are in any @options file.
   [The option /Y- appears to disable PCH completely.  You might try that if 
the above is not enough.)

   Don't have any #include "stdafx.h"

   Nuke any "stdafx.cpp" and "stdafx.h" files.

How you control this may be a function of (generated?) makefiles and parameters 
they set, and that's harder.  If there are some common @option files around, 
that's not so bad.

You may have to find where/how the command-line options are specified in any 
makefiles, and where those come from for generated files.

> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows




On 2/4/2016 3:36 PM, Damjan Jovanovic wrote:

On Thu, Feb 4, 2016 at 11:47 PM, Patricia Shanahan  wrote:


On 2/4/2016 12:40 PM, Regina Henschel wrote:


Hi Patricia,

Patricia Shanahan schrieb:


I think maybe I need to clean up and start again. What is the best way
to clean, short of doing a fresh checkout?



I remove the output-tree manually

Starting in main:
find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf

In addition delete wntmsci12* from folder solver.

In addition delete wntmsci12* from folders in ext_libraries



Thanks.

My next question is the best way to control the C compiler options. I want
to get rid of precompiled headers.



You're using precompiled headers because you passed --enable-pch to
./configure.



I think we should change the sample configure parameters in 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7


There is a serious bug in the Visual Studio C compiler that causes the 
"unexpected precompiled header error" failures, so enable-pch should not 
be suggested.


Patricia

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

Remember what I told you about main/icu: it doesn't build
deterministically, sometimes it fails and sometimes it passes for no
apparent reason, keep cleaning and rebuilding in its directory until it
builds then "deliver" and continue as before.

On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan  wrote:

> I had 25 consecutive "build --all" attempts fail, at different places, due
> to the retryable errors. The general behavior, and the fact that the
> frequency of failure varies from environment to environment, supports the
> theory that the failures are due to poorly managed multiprocessing.
>
> Accordingly, yesterday I started a completely clean build, from a fresh
> checkout, with enable_multiprocessing set to zero in both build.pl and
> build_client.pl. Is there anything else I need to do to suppress MP?
>
> That built attempt failed with the following error:
>
> NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
> return code '0x2'
> Stop.
> dmake:  Error code 2, while making './
> wntmsci12.pro/misc/build/so_built_so_icu'
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/icu
>
>
>
> On 2/4/2016 3:16 AM, Regina Henschel wrote:
>
>> Hi Patricia,
>>
>> I had sometimes curious build breaks because of parallelism and virus
>> scan. So please try to make a build without any parallelism and disable
>> virus scan. Additional benefit: without parallelism, the log tells you
>> the actual module order.
>>
>> Kind regards
>> Regina
>>
>> Patricia Shanahan schrieb:
>>
>>> Yes, there is certainly stuff to investigate. My latest failure is:
>>>
>>> /usr/bin/cp: missing destination file operand after
>>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>>> wntmsci12.pro/lib/isvl.lib'
>>>
>>>
>>> Try '/usr/bin/cp --help' for more information.
>>> C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
>>> for target
>>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>>> wntmsci12.pro/lib/isvl.lib'
>>>
>>> failed
>>> make: ***
>>> [/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>>> wntmsci12.pro/lib/isvl.lib]
>>>
>>> Error 1
>>> dmake:  Error code 2, while making 'all'
>>>
>>> 1 module(s):
>>>  xmloff
>>> need(s) to be rebuilt
>>>
>>> Reason(s):
>>>
>>> ERROR: error 65280 occurred while making
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj
>>>
>>> When you have fixed the errors in that module you can resume the build
>>> by running:
>>>
>>>  build --all:xmloff
>>>
>>>
>>> On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:
>>>
 main/oox/prj/build.lst already lists xmlscript as a dependency, so
 "build"
 should have built it before starting to build oox. Something must be
 very
 wrong for it not to.

 On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:

 Yes, thanks. At least, it gets past oox.
>
> So one trick for a missing file is to explicitly build and deliver in
> the
> directory the file should have come from.
>
> Later, I may do a new build from a clean check-out, and try to
> investigate
> anomalies. Right now, my objective is to just get it built.
>
>
> On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:
>
> That is strange. Does it work if you first do "build" and "deliver" in
>> main/xmlscript?
>>
>> On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan 
>> wrote:
>>
>> I am now getting to:
>>
>>>
>>> Compiling: oox/source/ole/vbacontrol.cxx
>>> C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
>>> error C1083: Cannot open include file:
>>> 'xmlscript/xmldlg_imexp.hxx': No
>>> such file or directory
>>> dmake:  Error code 2, while making '../../
>>> wntmsci12.pro/slo/vbacontrol.obj
>>> '
>>>
>>> 1 module(s):
>>>   oox
>>> need(s) to be rebuilt
>>>
>>> Reason(s):
>>>
>>> ERROR: error 65280 occurred while making
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole
>>>
>>>
>>>
>>> On 2/2/2016 9:33 PM, Patricia Shanahan wrote:
>>>
>>> python had apparently not been built. I don't know why. I was able to
>>>
 get the build going again with "build --all:python".

 It is now making progress, but from time-to-time I get this sort of
 failure:


 ==


 c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) :
 fatal
 error C1859:
 'c:/OpenOfficeDev/Trunk/main/solver/420/

 wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch


 '
 unexpected precompiled header error, simply rerunning the compiler
 might
 fix this

Re: Building on Windows

Thanks for the reminder. My plan for this morning was to search my mail 
archive for "icuin". I had hoped that getting rid of MP would get rid of 
this sort of non-determinism.


On 2/4/2016 6:30 AM, Damjan Jovanovic wrote:

Remember what I told you about main/icu: it doesn't build
deterministically, sometimes it fails and sometimes it passes for no
apparent reason, keep cleaning and rebuilding in its directory until it
builds then "deliver" and continue as before.

On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan  wrote:


I had 25 consecutive "build --all" attempts fail, at different places, due
to the retryable errors. The general behavior, and the fact that the
frequency of failure varies from environment to environment, supports the
theory that the failures are due to poorly managed multiprocessing.

Accordingly, yesterday I started a completely clean build, from a fresh
checkout, with enable_multiprocessing set to zero in both build.pl and
build_client.pl. Is there anything else I need to do to suppress MP?

That built attempt failed with the following error:

NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'
ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/icu



On 2/4/2016 3:16 AM, Regina Henschel wrote:


Hi Patricia,

I had sometimes curious build breaks because of parallelism and virus
scan. So please try to make a build without any parallelism and disable
virus scan. Additional benefit: without parallelism, the log tells you
the actual module order.

Kind regards
Regina

Patricia Shanahan schrieb:


Yes, there is certainly stuff to investigate. My latest failure is:

/usr/bin/cp: missing destination file operand after
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'


Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
for target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'

failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib]

Error 1
dmake:  Error code 2, while making 'all'

1 module(s):
  xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj

When you have fixed the errors in that module you can resume the build
by running:

  build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:


main/oox/prj/build.lst already lists xmlscript as a dependency, so
"build"
should have built it before starting to build oox. Something must be
very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:

Yes, thanks. At least, it gets past oox.


So one trick for a missing file is to explicitly build and deliver in
the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate
anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:

That is strange. Does it work if you first do "build" and "deliver" in

main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan 
wrote:

I am now getting to:



Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
error C1083: Cannot open include file:
'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../
wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
   oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was able to


get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:


==


c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) :
fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/

wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch


'
unexpected precompiled header error, simply rerunning the compiler
might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126:
recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making

Re: Building on Windows

I had 25 consecutive "build --all" attempts fail, at different places, 
due to the retryable errors. The general behavior, and the fact that the 
frequency of failure varies from environment to environment, supports 
the theory that the failures are due to poorly managed multiprocessing.


Accordingly, yesterday I started a completely clean build, from a fresh 
checkout, with enable_multiprocessing set to zero in both build.pl and 
build_client.pl. Is there anything else I need to do to suppress MP?


That built attempt failed with the following error:

NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' : 
return code '0x2'

Stop.
dmake:  Error code 2, while making 
'./wntmsci12.pro/misc/build/so_built_so_icu'
ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/icu



On 2/4/2016 3:16 AM, Regina Henschel wrote:

Hi Patricia,

I had sometimes curious build breaks because of parallelism and virus
scan. So please try to make a build without any parallelism and disable
virus scan. Additional benefit: without parallelism, the log tells you
the actual module order.

Kind regards
Regina

Patricia Shanahan schrieb:

Yes, there is certainly stuff to investigate. My latest failure is:

/usr/bin/cp: missing destination file operand after
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib'


Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
for target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib'

failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib]

Error 1
dmake:  Error code 2, while making 'all'

1 module(s):
 xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj

When you have fixed the errors in that module you can resume the build
by running:

 build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:

main/oox/prj/build.lst already lists xmlscript as a dependency, so
"build"
should have built it before starting to build oox. Something must be
very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:


Yes, thanks. At least, it gets past oox.

So one trick for a missing file is to explicitly build and deliver in
the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate
anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:


That is strange. Does it work if you first do "build" and "deliver" in
main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan 
wrote:

I am now getting to:


Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
error C1083: Cannot open include file:
'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../
wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
  oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was able to

get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:

==


c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) :
fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch


'
unexpected precompiled header error, simply rerunning the compiler
might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126:
recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
   svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the
build
by running:

   build --all:svl
==



The build system knows the failure is potentially retriable. It
tells me
exactly what to type to do the retry. WHY can't it just retry
itself,
without needing my fingers on the keyboard?



On 2/2/2016 8:10 AM, Patricia Shanahan wrote:

OpenGrok looks and sounds like something I should learn about.


I think my next step is to look into the

RE: Building on Windows

2016-02-04 Thread Dennis E. Hamilton

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Wednesday, February 3, 2016 08:16
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
[ ... ]
> 
> I have some hypotheses about my current problems. Is there a master list
> of build targets and dependencies? If so, where?
[orcmid] 

I don't know about a master list, but those building release candidates and 
then releases must have something that works those cases.  

For me, replicating the builds for binaries that the project ships would seem 
to be crucial.  Hence, my concerns about the on-Windows build that builds the 
Windows binary, where the only specific variation is the language localization.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


I got icu to build. Here is my latest failure:

C:\OpenOfficeDev\Trunk\main\offapi\com\sun\star\sdb\XRowSetChangeListener.idl(45) 
: WARNING, type or identifier doesn't fulfill the UNO naming convention: 
i_Event
dmake:  /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/inc/target.mk:  line 
583:  Warning: -- Macro `SHL2TARGETN' redefined after use

rm: cannot remove '../wntmsci12.pro/misc/qa.rdb': No such file or directory
dmake:  Error code 2, while making '../wntmsci12.pro/slo/test_reference.obj'

1 module(s):
cppu
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/cppu/qa



On 2/4/2016 6:53 AM, Patricia Shanahan wrote:

Thanks for the reminder. My plan for this morning was to search my mail
archive for "icuin". I had hoped that getting rid of MP would get rid of
this sort of non-determinism.

On 2/4/2016 6:30 AM, Damjan Jovanovic wrote:

Remember what I told you about main/icu: it doesn't build
deterministically, sometimes it fails and sometimes it passes for no
apparent reason, keep cleaning and rebuilding in its directory until it
builds then "deliver" and continue as before.

On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan  wrote:


I had 25 consecutive "build --all" attempts fail, at different
places, due
to the retryable errors. The general behavior, and the fact that the
frequency of failure varies from environment to environment, supports
the
theory that the failures are due to poorly managed multiprocessing.

Accordingly, yesterday I started a completely clean build, from a fresh
checkout, with enable_multiprocessing set to zero in both build.pl and
build_client.pl. Is there anything else I need to do to suppress MP?

That built attempt failed with the following error:

NMAKE : fatal error U1073: don't know how to make
'".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'
ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/icu



On 2/4/2016 3:16 AM, Regina Henschel wrote:


Hi Patricia,

I had sometimes curious build breaks because of parallelism and virus
scan. So please try to make a build without any parallelism and disable
virus scan. Additional benefit: without parallelism, the log tells you
the actual module order.

Kind regards
Regina

Patricia Shanahan schrieb:


Yes, there is certainly stuff to investigate. My latest failure is:

/usr/bin/cp: missing destination file operand after
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'


Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
for target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'

failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib]

Error 1
dmake:  Error code 2, while making 'all'

1 module(s):
  xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj

When you have fixed the errors in that module you can resume the build
by running:

  build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:


main/oox/prj/build.lst already lists xmlscript as a dependency, so
"build"
should have built it before starting to build oox. Something must be
very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan 
wrote:

Yes, thanks. At least, it gets past oox.


So one trick for a missing file is to explicitly build and
deliver in
the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate
anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:

That is strange. Does it work if you first do "build" and
"deliver" in

main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan 
wrote:

I am now getting to:



Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) :
fatal
error C1083: Cannot open include file:
'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../
wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
   oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was
able to


get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this
sort of
failure:


==



c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) :
fatal
error C1859:

Re: Building on Windows

That's just a unit test, although main/cppu/qa/makefile.mk should really be
ignoring failures in rm:

$(MISC)$/$(TARGET).rdb: $(MISC)$/$(TARGET)$/types.urd
- rm $@
$(REGMERGE) $@ /UCR $<

Try "ENABLE_UNIT_TESTS=NO build"


On Thu, Feb 4, 2016 at 6:51 PM, Patricia Shanahan  wrote:

> I got icu to build. Here is my latest failure:
>
> C:\OpenOfficeDev\Trunk\main\offapi\com\sun\star\sdb\XRowSetChangeListener.idl(45)
> : WARNING, type or identifier doesn't fulfill the UNO naming convention:
> i_Event
> dmake:  /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/inc/target.mk:  line
> 583:  Warning: -- Macro `SHL2TARGETN' redefined after use
> rm: cannot remove '../wntmsci12.pro/misc/qa.rdb': No such file or
> directory
> dmake:  Error code 2, while making '../
> wntmsci12.pro/slo/test_reference.obj'
>
> 1 module(s):
> cppu
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/cppu/qa
>
>
>
> On 2/4/2016 6:53 AM, Patricia Shanahan wrote:
>
>> Thanks for the reminder. My plan for this morning was to search my mail
>> archive for "icuin". I had hoped that getting rid of MP would get rid of
>> this sort of non-determinism.
>>
>> On 2/4/2016 6:30 AM, Damjan Jovanovic wrote:
>>
>>> Remember what I told you about main/icu: it doesn't build
>>> deterministically, sometimes it fails and sometimes it passes for no
>>> apparent reason, keep cleaning and rebuilding in its directory until it
>>> builds then "deliver" and continue as before.
>>>
>>> On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan  wrote:
>>>
>>> I had 25 consecutive "build --all" attempts fail, at different
 places, due
 to the retryable errors. The general behavior, and the fact that the
 frequency of failure varies from environment to environment, supports
 the
 theory that the failures are due to poorly managed multiprocessing.

 Accordingly, yesterday I started a completely clean build, from a fresh
 checkout, with enable_multiprocessing set to zero in both build.pl and
 build_client.pl. Is there anything else I need to do to suppress MP?

 That built attempt failed with the following error:

 NMAKE : fatal error U1073: don't know how to make
 '".\..\..\lib\icuin.lib"'
 Stop.
 NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
 return code '0x2'
 Stop.
 dmake:  Error code 2, while making './
 wntmsci12.pro/misc/build/so_built_so_icu'
 ERROR: error 65280 occurred while making
 /cygdrive/c/OpenOfficeDev/Trunk/main/icu



 On 2/4/2016 3:16 AM, Regina Henschel wrote:

 Hi Patricia,
>
> I had sometimes curious build breaks because of parallelism and virus
> scan. So please try to make a build without any parallelism and disable
> virus scan. Additional benefit: without parallelism, the log tells you
> the actual module order.
>
> Kind regards
> Regina
>
> Patricia Shanahan schrieb:
>
> Yes, there is certainly stuff to investigate. My latest failure is:
>>
>> /usr/bin/cp: missing destination file operand after
>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/lib/isvl.lib'
>>
>>
>> Try '/usr/bin/cp --help' for more information.
>> C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
>> for target
>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/lib/isvl.lib'
>>
>> failed
>> make: ***
>> [/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/lib/isvl.lib]
>>
>> Error 1
>> dmake:  Error code 2, while making 'all'
>>
>> 1 module(s):
>>   xmloff
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj
>>
>> When you have fixed the errors in that module you can resume the build
>> by running:
>>
>>   build --all:xmloff
>>
>>
>> On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:
>>
>> main/oox/prj/build.lst already lists xmlscript as a dependency, so
>>> "build"
>>> should have built it before starting to build oox. Something must be
>>> very
>>> wrong for it not to.
>>>
>>> On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan 
>>> wrote:
>>>
>>> Yes, thanks. At least, it gets past oox.
>>>

 So one trick for a missing file is to explicitly build and
 deliver in
 the
 directory the file should have come from.

 Later, I may do a new build from a clean check-out, and try to
 investigate
 anomalies. Right now, my objective is to just get it built.


 On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:

 That is strange.

Re: Building on Windows

I think maybe I need to clean up and start again. What is the best way 
to clean, short of doing a fresh checkout?


Patricia@Jan2014Desktop 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native

$ ENABLE_UNIT_TESTS=NO build 2>&1 |tee wk3
build -- version: 275224


=
Building module instsetoo_native
=

Entering 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages


/usr/bin/bash: 
C:/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/bin/ulfconv: No 
such file or directory
dmake:  Error code 127, while making 
'../../../wntmsci12.pro/misc/win_ulffiles/ActionTe.mlf'
ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages



On 2/4/2016 9:19 AM, Damjan Jovanovic wrote:

That's just a unit test, although main/cppu/qa/makefile.mk should really be
ignoring failures in rm:

$(MISC)$/$(TARGET).rdb: $(MISC)$/$(TARGET)$/types.urd
 - rm $@
 $(REGMERGE) $@ /UCR $<

Try "ENABLE_UNIT_TESTS=NO build"


On Thu, Feb 4, 2016 at 6:51 PM, Patricia Shanahan  wrote:


I got icu to build. Here is my latest failure:

C:\OpenOfficeDev\Trunk\main\offapi\com\sun\star\sdb\XRowSetChangeListener.idl(45)
: WARNING, type or identifier doesn't fulfill the UNO naming convention:
i_Event
dmake:  /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/inc/target.mk:  line
583:  Warning: -- Macro `SHL2TARGETN' redefined after use
rm: cannot remove '../wntmsci12.pro/misc/qa.rdb': No such file or
directory
dmake:  Error code 2, while making '../
wntmsci12.pro/slo/test_reference.obj'

1 module(s):
 cppu
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/cppu/qa



On 2/4/2016 6:53 AM, Patricia Shanahan wrote:


Thanks for the reminder. My plan for this morning was to search my mail
archive for "icuin". I had hoped that getting rid of MP would get rid of
this sort of non-determinism.

On 2/4/2016 6:30 AM, Damjan Jovanovic wrote:


Remember what I told you about main/icu: it doesn't build
deterministically, sometimes it fails and sometimes it passes for no
apparent reason, keep cleaning and rebuilding in its directory until it
builds then "deliver" and continue as before.

On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan  wrote:

I had 25 consecutive "build --all" attempts fail, at different

places, due
to the retryable errors. The general behavior, and the fact that the
frequency of failure varies from environment to environment, supports
the
theory that the failures are due to poorly managed multiprocessing.

Accordingly, yesterday I started a completely clean build, from a fresh
checkout, with enable_multiprocessing set to zero in both build.pl and
build_client.pl. Is there anything else I need to do to suppress MP?

That built attempt failed with the following error:

NMAKE : fatal error U1073: don't know how to make
'".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'
ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/icu



On 2/4/2016 3:16 AM, Regina Henschel wrote:

Hi Patricia,


I had sometimes curious build breaks because of parallelism and virus
scan. So please try to make a build without any parallelism and disable
virus scan. Additional benefit: without parallelism, the log tells you
the actual module order.

Kind regards
Regina

Patricia Shanahan schrieb:

Yes, there is certainly stuff to investigate. My latest failure is:


/usr/bin/cp: missing destination file operand after
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'


Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe
for target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib'

failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/lib/isvl.lib]

Error 1
dmake:  Error code 2, while making 'all'

1 module(s):
   xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj

When you have fixed the errors in that module you can resume the build
by running:

   build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:

main/oox/prj/build.lst already lists xmlscript as a dependency, so

"build"
should have built it before starting to build oox. Something must be
very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan 
wrote:

Yes, thanks. At least, it gets past oox.



So one trick for a missing file is to explicitly build and
deliver in
the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate
anomalies. Right now, my objective is

Re: Building on Windows

Cleaning is covered in
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
which currently seems down?

Personally I use "dmake clean" in main, and if I really want to delete
absolutely every new file since SVN checkout:
svn revert * -R
svn status | while read i; do rm -rf "${i:8}"; done
The latter has the disadvantage of losing all the useful third party DLLs
in main/external, so back them up first.


On Thu, Feb 4, 2016 at 8:07 PM, Patricia Shanahan  wrote:

> I think maybe I need to clean up and start again. What is the best way to
> clean, short of doing a fresh checkout?
>
> Patricia@Jan2014Desktop
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native
> $ ENABLE_UNIT_TESTS=NO build 2>&1 |tee wk3
> build -- version: 275224
>
>
> =
> Building module instsetoo_native
> =
>
> Entering
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
>
> /usr/bin/bash: C:/OpenOfficeDev/Trunk/main/solver/420/
> wntmsci12.pro/bin/ulfconv: No such file or directory
> dmake:  Error code 127, while making '../../../
> wntmsci12.pro/misc/win_ulffiles/ActionTe.mlf'
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native/inc_openoffice/windows/msi_languages
>
>
>
> On 2/4/2016 9:19 AM, Damjan Jovanovic wrote:
>
>> That's just a unit test, although main/cppu/qa/makefile.mk should really
>> be
>> ignoring failures in rm:
>>
>> $(MISC)$/$(TARGET).rdb: $(MISC)$/$(TARGET)$/types.urd
>>  - rm $@
>>  $(REGMERGE) $@ /UCR $<
>>
>> Try "ENABLE_UNIT_TESTS=NO build"
>>
>>
>> On Thu, Feb 4, 2016 at 6:51 PM, Patricia Shanahan  wrote:
>>
>> I got icu to build. Here is my latest failure:
>>>
>>>
>>> C:\OpenOfficeDev\Trunk\main\offapi\com\sun\star\sdb\XRowSetChangeListener.idl(45)
>>> : WARNING, type or identifier doesn't fulfill the UNO naming convention:
>>> i_Event
>>> dmake:  /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/inc/target.mk:  line
>>> 583:  Warning: -- Macro `SHL2TARGETN' redefined after use
>>> rm: cannot remove '../wntmsci12.pro/misc/qa.rdb': No such file or
>>> directory
>>> dmake:  Error code 2, while making '../
>>> wntmsci12.pro/slo/test_reference.obj'
>>>
>>> 1 module(s):
>>>  cppu
>>> need(s) to be rebuilt
>>>
>>> Reason(s):
>>>
>>> ERROR: error 65280 occurred while making
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/cppu/qa
>>>
>>>
>>>
>>> On 2/4/2016 6:53 AM, Patricia Shanahan wrote:
>>>
>>> Thanks for the reminder. My plan for this morning was to search my mail
 archive for "icuin". I had hoped that getting rid of MP would get rid of
 this sort of non-determinism.

 On 2/4/2016 6:30 AM, Damjan Jovanovic wrote:

 Remember what I told you about main/icu: it doesn't build
> deterministically, sometimes it fails and sometimes it passes for no
> apparent reason, keep cleaning and rebuilding in its directory until it
> builds then "deliver" and continue as before.
>
> On Thu, Feb 4, 2016 at 4:21 PM, Patricia Shanahan 
> wrote:
>
> I had 25 consecutive "build --all" attempts fail, at different
>
>> places, due
>> to the retryable errors. The general behavior, and the fact that the
>> frequency of failure varies from environment to environment, supports
>> the
>> theory that the failures are due to poorly managed multiprocessing.
>>
>> Accordingly, yesterday I started a completely clean build, from a
>> fresh
>> checkout, with enable_multiprocessing set to zero in both build.pl
>> and
>> build_client.pl. Is there anything else I need to do to suppress MP?
>>
>> That built attempt failed with the following error:
>>
>> NMAKE : fatal error U1073: don't know how to make
>> '".\..\..\lib\icuin.lib"'
>> Stop.
>> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
>> return code '0x2'
>> Stop.
>> dmake:  Error code 2, while making './
>> wntmsci12.pro/misc/build/so_built_so_icu'
>> ERROR: error 65280 occurred while making
>> /cygdrive/c/OpenOfficeDev/Trunk/main/icu
>>
>>
>>
>> On 2/4/2016 3:16 AM, Regina Henschel wrote:
>>
>> Hi Patricia,
>>
>>>
>>> I had sometimes curious build breaks because of parallelism and virus
>>> scan. So please try to make a build without any parallelism and
>>> disable
>>> virus scan. Additional benefit: without parallelism, the log tells
>>> you
>>> the actual module order.
>>>
>>> Kind regards
>>> Regina
>>>
>>> Patricia Shanahan schrieb:
>>>
>>> Yes, there is certainly stuff to investigate. My latest failure is:
>>>

 /usr/bin/cp: missing destination file operand after
 '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
 wntmsci12.pro/lib/isvl.lib'


 Try '/usr/bin/cp --help' for more information.

Re: Building on Windows

2016-02-04 Thread Regina Henschel


Hi Patricia,

Patricia Shanahan schrieb:

I think maybe I need to clean up and start again. What is the best way
to clean, short of doing a fresh checkout?


I remove the output-tree manually

Starting in main:
find . -maxdepth 2 -name "wntmsci12*" | xargs rm -rf

In addition delete wntmsci12* from folder solver.

In addition delete wntmsci12* from folders in ext_libraries

Kind regards
Regina


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


Yes, thanks. At least, it gets past oox.

So one trick for a missing file is to explicitly build and deliver in 
the directory the file should have come from.


Later, I may do a new build from a clean check-out, and try to 
investigate anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:

That is strange. Does it work if you first do "build" and "deliver" in
main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan  wrote:


I am now getting to:

Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
error C1083: Cannot open include file: 'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
 oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:


python had apparently not been built. I don't know why. I was able to
get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:

==
c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch'
unexpected precompiled header error, simply rerunning the compiler might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
  svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the build
by running:

  build --all:svl
==

The build system knows the failure is potentially retriable. It tells me
exactly what to type to do the retry. WHY can't it just retry itself,
without needing my fingers on the keyboard?



On 2/2/2016 8:10 AM, Patricia Shanahan wrote:


OpenGrok looks and sounds like something I should learn about.

I think my next step is to look into the state of python. Matters may
have been complicated because I did a "dmake clean" after changing my
configure parameters to use a 32 bit JDK, before continuing the steps
from configure on.

There may be a pause - I have some non-programming stuff to do today and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle things
out for myself first.

On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:


OpenGrok[1] tells me the pyversion.mk file is in main/python; through
building it would get delivered to main/solver/... and found by pyuno.
Did
python not build before pyuno did? pyuno/prj/build.lst lists a
dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools
PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the
python
module isn't getting built first, you can force it to build first
through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd ../instsetoo_native
build --all -P2 -- -P2

References:
[1]

http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk


[2]

http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst



On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:

Thanks. Now I get to:


=
Building module pyuno
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module

mkout -- version: 1.8
dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk,
not
found





On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:

For me, main/icu fails to build on Windows about 50% of the time

for no
apparent reason; I've begun to think it's some sort of build race
condition
within that module. I haven't seen the buildbots fail there, and
nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd

Re: Building on Windows


I am now getting to:

Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal 
error C1083: Cannot open include file: 'xmlscript/xmldlg_imexp.hxx': No 
such file or directory

dmake:  Error code 2, while making '../../wntmsci12.pro/slo/vbacontrol.obj'

1 module(s):
oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was able to
get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:

==
c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch'
unexpected precompiled header error, simply rerunning the compiler might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
 svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the build
by running:

 build --all:svl
==

The build system knows the failure is potentially retriable. It tells me
exactly what to type to do the retry. WHY can't it just retry itself,
without needing my fingers on the keyboard?



On 2/2/2016 8:10 AM, Patricia Shanahan wrote:

OpenGrok looks and sounds like something I should learn about.

I think my next step is to look into the state of python. Matters may
have been complicated because I did a "dmake clean" after changing my
configure parameters to use a 32 bit JDK, before continuing the steps
from configure on.

There may be a pause - I have some non-programming stuff to do today and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle things
out for myself first.

On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:

OpenGrok[1] tells me the pyversion.mk file is in main/python; through
building it would get delivered to main/solver/... and found by pyuno.
Did
python not build before pyuno did? pyuno/prj/build.lst lists a
dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools
PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the
python
module isn't getting built first, you can force it to build first
through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd ../instsetoo_native
build --all -P2 -- -P2

References:
[1]
http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk


[2]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst



On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:


Thanks. Now I get to:

=
Building module pyuno
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module

mkout -- version: 1.8
dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk,
not
found





On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:


For me, main/icu fails to build on Windows about 50% of the time
for no
apparent reason; I've begun to think it's some sort of build race
condition
within that module. I haven't seen the buildbots fail there, and
nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd ../instsetoo_native
build --all -P2 -- -P2


On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan 
wrote:

Good. My latest error is:


NMAKE : fatal error U1073: don't know how to make
'".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077:
'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'

I am hoping after this is all done to add a section on gotchas and
their
symptoms to the step-by-step guide. That may

Re: Building on Windows

2016-02-03 Thread Damjan Jovanovic

That is strange. Does it work if you first do "build" and "deliver" in
main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan  wrote:

> I am now getting to:
>
> Compiling: oox/source/ole/vbacontrol.cxx
> C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
> error C1083: Cannot open include file: 'xmlscript/xmldlg_imexp.hxx': No
> such file or directory
> dmake:  Error code 2, while making '../../wntmsci12.pro/slo/vbacontrol.obj
> '
>
> 1 module(s):
> oox
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole
>
>
>
> On 2/2/2016 9:33 PM, Patricia Shanahan wrote:
>
>> python had apparently not been built. I don't know why. I was able to
>> get the build going again with "build --all:python".
>>
>> It is now making progress, but from time-to-time I get this sort of
>> failure:
>>
>> ==
>> c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
>> error C1859:
>> 'c:/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch'
>> unexpected precompiled header error, simply rerunning the compiler might
>> fix this problem
>> C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe for
>> target
>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
>> failed
>> make: ***
>> [/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
>> Error 2
>> dmake:  Error code 2, while making 'all'
>>
>> 1 module(s):
>>  svl
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj
>>
>> When you have fixed the errors in that module you can resume the build
>> by running:
>>
>>  build --all:svl
>> ==
>>
>> The build system knows the failure is potentially retriable. It tells me
>> exactly what to type to do the retry. WHY can't it just retry itself,
>> without needing my fingers on the keyboard?
>>
>>
>>
>> On 2/2/2016 8:10 AM, Patricia Shanahan wrote:
>>
>>> OpenGrok looks and sounds like something I should learn about.
>>>
>>> I think my next step is to look into the state of python. Matters may
>>> have been complicated because I did a "dmake clean" after changing my
>>> configure parameters to use a 32 bit JDK, before continuing the steps
>>> from configure on.
>>>
>>> There may be a pause - I have some non-programming stuff to do today and
>>> tomorrow morning.
>>>
>>> Thanks for all the help. Posting immediately on hitting a problem is
>>> definitely getting faster progress than when I tried to puzzle things
>>> out for myself first.
>>>
>>> On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:
>>>
 OpenGrok[1] tells me the pyversion.mk file is in main/python; through
 building it would get delivered to main/solver/... and found by pyuno.
 Did
 python not build before pyuno did? pyuno/prj/build.lst lists a
 dependency
 on python when PYTHON is defined[2]:

 bgpupyuno   :   stoc cpputools cppuhelper bridges tools
 PYTHON:python
 LIBXSLT:libxslt NULL

 but earlier you posted your config.log which had this in it:

 PYTHON=''

 and I am not sure whether that's enough. If the problem is that the
 python
 module isn't getting built first, you can force it to build first
 through
 one of these hacks:
 * delete the "PYTHON:" prefix to "python" from the build.lst line
 * manually building python before resuming the build:
 cd main/python
 build
 deliver
 cd ../instsetoo_native
 build --all -P2 -- -P2

 References:
 [1]

 http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk


 [2]

 http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst



 On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:

 Thanks. Now I get to:
>
> =
> Building module pyuno
> =
>
> Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module
>
> mkout -- version: 1.8
> dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk,
> not
> found
>
>
>
>
>
> On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:
>
> For me, main/icu fails to build on Windows about 50% of the time
>> for no
>> apparent reason; I've begun to think it's some sort of build race
>> condition
>> within that module. I haven't seen the buildbots fail there, and
>> nobody
>> else has reported this problem.
>>
>> If this is your problem, the only fix I know is the

Re: Building on Windows


Yes, there is certainly stuff to investigate. My latest failure is:

/usr/bin/cp: missing destination file operand after 
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib'

Try '/usr/bin/cp --help' for more information.
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe 
for target 
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib' 
failed
make: *** 
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/lib/isvl.lib] 
Error 1

dmake:  Error code 2, while making 'all'

1 module(s):
xmloff
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making 
/cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj


When you have fixed the errors in that module you can resume the build 
by running:


build --all:xmloff


On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:

main/oox/prj/build.lst already lists xmlscript as a dependency, so "build"
should have built it before starting to build oox. Something must be very
wrong for it not to.

On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:


Yes, thanks. At least, it gets past oox.

So one trick for a missing file is to explicitly build and deliver in the
directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to investigate
anomalies. Right now, my objective is to just get it built.


On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:


That is strange. Does it work if you first do "build" and "deliver" in
main/xmlscript?

On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan  wrote:

I am now getting to:


Compiling: oox/source/ole/vbacontrol.cxx
C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
error C1083: Cannot open include file: 'xmlscript/xmldlg_imexp.hxx': No
such file or directory
dmake:  Error code 2, while making '../../
wntmsci12.pro/slo/vbacontrol.obj
'

1 module(s):
  oox
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole



On 2/2/2016 9:33 PM, Patricia Shanahan wrote:

python had apparently not been built. I don't know why. I was able to

get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of
failure:

==
c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch
'
unexpected precompiled header error, simply rerunning the compiler might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2
dmake:  Error code 2, while making 'all'

1 module(s):
   svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the build
by running:

   build --all:svl
==

The build system knows the failure is potentially retriable. It tells me
exactly what to type to do the retry. WHY can't it just retry itself,
without needing my fingers on the keyboard?



On 2/2/2016 8:10 AM, Patricia Shanahan wrote:

OpenGrok looks and sounds like something I should learn about.


I think my next step is to look into the state of python. Matters may
have been complicated because I did a "dmake clean" after changing my
configure parameters to use a 32 bit JDK, before continuing the steps
from configure on.

There may be a pause - I have some non-programming stuff to do today
and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle things
out for myself first.

On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:

OpenGrok[1] tells me the pyversion.mk file is in main/python; through

building it would get delivered to main/solver/... and found by pyuno.
Did
python not build before pyuno did? pyuno/prj/build.lst lists a
dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools
PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the
python
module isn't getting built first, you can force it to build first
through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd

Re: Building on Windows

2016-02-03 Thread Damjan Jovanovic

Are you using build --all?

I am not sure what else could be wrong there. Something probably built in
the wrong order. You might have to start from the beginning...

On Wed, Feb 3, 2016 at 1:37 PM, Patricia Shanahan  wrote:

> Yes, there is certainly stuff to investigate. My latest failure is:
>
> /usr/bin/cp: missing destination file operand after
> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
> wntmsci12.pro/lib/isvl.lib'
> Try '/usr/bin/cp --help' for more information.
> C:/OpenOfficeDev/Trunk/main/solenv/gbuild/StaticLibrary.mk:45: recipe for
> target '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
> wntmsci12.pro/lib/isvl.lib' failed
> make: *** [/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
> wntmsci12.pro/lib/isvl.lib] Error 1
> dmake:  Error code 2, while making 'all'
>
> 1 module(s):
> xmloff
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/xmloff/prj
>
> When you have fixed the errors in that module you can resume the build by
> running:
>
> build --all:xmloff
>
>
>
> On 2/3/2016 3:33 AM, Damjan Jovanovic wrote:
>
>> main/oox/prj/build.lst already lists xmlscript as a dependency, so "build"
>> should have built it before starting to build oox. Something must be very
>> wrong for it not to.
>>
>> On Wed, Feb 3, 2016 at 1:28 PM, Patricia Shanahan  wrote:
>>
>> Yes, thanks. At least, it gets past oox.
>>>
>>> So one trick for a missing file is to explicitly build and deliver in the
>>> directory the file should have come from.
>>>
>>> Later, I may do a new build from a clean check-out, and try to
>>> investigate
>>> anomalies. Right now, my objective is to just get it built.
>>>
>>>
>>> On 2/3/2016 3:19 AM, Damjan Jovanovic wrote:
>>>
>>> That is strange. Does it work if you first do "build" and "deliver" in
 main/xmlscript?

 On Wed, Feb 3, 2016 at 1:07 PM, Patricia Shanahan  wrote:

 I am now getting to:

>
> Compiling: oox/source/ole/vbacontrol.cxx
> C:/OpenOfficeDev/Trunk/main/oox/source/ole/vbacontrol.cxx(34) : fatal
> error C1083: Cannot open include file: 'xmlscript/xmldlg_imexp.hxx': No
> such file or directory
> dmake:  Error code 2, while making '../../
> wntmsci12.pro/slo/vbacontrol.obj
> '
>
> 1 module(s):
>   oox
> need(s) to be rebuilt
>
> Reason(s):
>
> ERROR: error 65280 occurred while making
> /cygdrive/c/OpenOfficeDev/Trunk/main/oox/source/ole
>
>
>
> On 2/2/2016 9:33 PM, Patricia Shanahan wrote:
>
> python had apparently not been built. I don't know why. I was able to
>
>> get the build going again with "build --all:python".
>>
>> It is now making progress, but from time-to-time I get this sort of
>> failure:
>>
>> ==
>> c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
>> error C1859:
>> 'c:/OpenOfficeDev/Trunk/main/solver/420/
>>
>> wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch
>> '
>> unexpected precompiled header error, simply rerunning the compiler
>> might
>> fix this problem
>> C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe
>> for
>> target
>> '/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
>> failed
>> make: ***
>> [/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/
>> wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
>> Error 2
>> dmake:  Error code 2, while making 'all'
>>
>> 1 module(s):
>>svl
>> need(s) to be rebuilt
>>
>> Reason(s):
>>
>> ERROR: error 65280 occurred while making
>> /cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj
>>
>> When you have fixed the errors in that module you can resume the build
>> by running:
>>
>>build --all:svl
>> ==
>>
>> The build system knows the failure is potentially retriable. It tells
>> me
>> exactly what to type to do the retry. WHY can't it just retry itself,
>> without needing my fingers on the keyboard?
>>
>>
>>
>> On 2/2/2016 8:10 AM, Patricia Shanahan wrote:
>>
>> OpenGrok looks and sounds like something I should learn about.
>>
>>>
>>> I think my next step is to look into the state of python. Matters may
>>> have been complicated because I did a "dmake clean" after changing my
>>> configure parameters to use a 32 bit JDK, before continuing the steps
>>> from configure on.
>>>
>>> There may be a pause - I have some non-programming stuff to do today
>>> and
>>> tomorrow morning.
>>>
>>> Thanks for all the help.

RE: Building on Windows

2016-02-03 Thread Dennis E. Hamilton


> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Wednesday, February 3, 2016 03:29
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
> Yes, thanks. At least, it gets past oox.
> 
> So one trick for a missing file is to explicitly build and deliver in
> the directory the file should have come from.
> 
> Later, I may do a new build from a clean check-out, and try to
> investigate anomalies. Right now, my objective is to just get it built.
> 
[orcmid] 
One thing that I have my eye on when the dust settles on this is ensuring that 
release candidate source can be built, since it is a condition on being able to 
release.  This means the release-candidate .tar.gz is downloaded and used. 

(If there is a .zip, that would presumably have different text-file line 
endings if produced on a Windows machine, so the native versus CRLF versus LF 
business raises its head, along with some other matters where Zips have 
platform irregularities. [;<).

I have an attitude problem about how contorted this is from a Windows 
development perspective.  I will work on adjusting that.

In any case, we will need to somehow need to provide sufficient information in 
an RC that it can be built any time later by someone able to replicate the 
specified prerequisites and setup.

Patricia, I pray good fortune to you.  We need a complete, repeatable guide for 
all of this.
[ ... ]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

On 2/3/2016 8:04 AM, Dennis E. Hamilton wrote:

-Original Message-
From: Patricia Shanahan [mailto:p...@acm.org]
Sent: Wednesday, February 3, 2016 03:29
To: dev@openoffice.apache.org
Subject: Re: Building on Windows

Yes, thanks. At least, it gets past oox.

So one trick for a missing file is to explicitly build and deliver in
the directory the file should have come from.

Later, I may do a new build from a clean check-out, and try to
investigate anomalies. Right now, my objective is to just get it built.

[orcmid]
One thing that I have my eye on when the dust settles on this is ensuring that 
release candidate source can be built, since it is a condition on being able to 
release.  This means the release-candidate .tar.gz is downloaded and used.

(If there is a .zip, that would presumably have different text-file line endings 
if produced on a Windows machine, so the native versus CRLF versus LF business 
raises its head, along with some other matters where Zips have platform 
irregularities. [;<).

I have an attitude problem about how contorted this is from a Windows 
development perspective.  I will work on adjusting that.

In any case, we will need to somehow need to provide sufficient information in 
an RC that it can be built any time later by someone able to replicate the 
specified prerequisites and setup.

Patricia, I pray good fortune to you.  We need a complete, repeatable guide for 
all of this.
[ ... ]

I have some hypotheses about my current problems. Is there a master list 
of build targets and dependencies? If so, where?

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-03 Thread Damjan Jovanovic

On Wed, Feb 3, 2016 at 6:16 PM, Patricia Shanahan <p...@acm.org> wrote:

> On 2/3/2016 8:04 AM, Dennis E. Hamilton wrote:
>
>>
>> -Original Message-
>>> From: Patricia Shanahan [mailto:p...@acm.org]
>>> Sent: Wednesday, February 3, 2016 03:29
>>> To: dev@openoffice.apache.org
>>> Subject: Re: Building on Windows
>>>
>>> Yes, thanks. At least, it gets past oox.
>>>
>>> So one trick for a missing file is to explicitly build and deliver in
>>> the directory the file should have come from.
>>>
>>> Later, I may do a new build from a clean check-out, and try to
>>> investigate anomalies. Right now, my objective is to just get it built.
>>>
>>> [orcmid]
>> One thing that I have my eye on when the dust settles on this is ensuring
>> that release candidate source can be built, since it is a condition on
>> being able to release.  This means the release-candidate .tar.gz is
>> downloaded and used.
>>
>> (If there is a .zip, that would presumably have different text-file line
>> endings if produced on a Windows machine, so the native versus CRLF versus
>> LF business raises its head, along with some other matters where Zips have
>> platform irregularities. [;<).
>>
>> I have an attitude problem about how contorted this is from a Windows
>> development perspective.  I will work on adjusting that.
>>
>> In any case, we will need to somehow need to provide sufficient
>> information in an RC that it can be built any time later by someone able to
>> replicate the specified prerequisites and setup.
>>
>> Patricia, I pray good fortune to you.  We need a complete, repeatable
>> guide for all of this.
>> [ ... ]
>>
>
> I have some hypotheses about my current problems. Is there a master list
> of build targets and dependencies? If so, where?
>
>
We have 2 build systems, the old dmake from the 1980's that most modules
use, and the new gbuild based on GNU make for a few modules that have been
migrated to it, with a third using xml files that was started but never
finished and isn't actually used.

I am not sure about your list. The *.mk files in main do list the projects
used by gbuild. The overall list would be used by build(.pl) (which
delegates to dmake or gbuild for the modules) but I am not sure where it
is. You could generate a list of builds targets and their dependencies with
this command from main:
ls */prj/build.lst
and reading the first line from each.

Re: Building on Windows


On 2/2/2016 9:25 AM, Damjan Jovanovic wrote:

On Tue, Feb 2, 2016 at 6:10 PM, Patricia Shanahan  wrote:


OpenGrok looks and sounds like something I should learn about.

I think my next step is to look into the state of python. Matters may have
been complicated because I did a "dmake clean" after changing my configure
parameters to use a 32 bit JDK, before continuing the steps from configure
on.



Yes, I think "dmake clean" requires re-running configure, bootstrap, source
winenv.set.sh and only then build.



There may be a pause - I have some non-programming stuff to do today and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle things out
for myself first.



It's a pleasure, sorry it's so hard, and thank you for your perseverance
through this building nightmare.


I hope that I'll later be able to use the log I'm creating through these 
e-mail messages to add a section to the build documents on what can go 
wrong, how to prevent it, and what to do afterwards. That may make the 
process easier in the future.




I think Sun Microsystems really had a knack for "comedy build systems" as
someone described them. OpenJDK was similarly painful to compile,
especially when they first open-sourced it.


I used to work for Sun, but as a large server architect, not on the Java 
or StarOffice side of things. If you think software builds are bad, try 
making changes to the design of an ASIC.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


On 2/2/2016 4:34 PM, Greg Bullock wrote:


On 2/1/2016 3:33 PM, Patricia Shanahan wrote:

...

Thanks for looking into it. It appears to probably be, ultimately, an
issue with TortoiseSVN mangling line endings. I am redoing the
checkout using Cygwin's command line svn. Once that is done, I'll copy
over a few things from the old tree, and try again from autoconf on.

Patricia


I know you've already moved on to cygwin's command line svn, but for
completeness: I believe TortoiseSVN lets you set options for whether and
how line endings should be handled on checkout.


I found some information about that, but it was not clear how to set
"don't mess with the endings at all" for an entire source tree.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

python had apparently not been built. I don't know why. I was able to
get the build going again with "build --all:python".

It is now making progress, but from time-to-time I get this sort of failure:

==
c:/OpenOfficeDev/Trunk/main/svl/source/numbers/zformat.cxx(25) : fatal
error C1859:
'c:/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/PrecompiledHeader/nodebug/precompiled_svl.hxx.pch'
unexpected precompiled header error, simply rerunning the compiler might
fix this problem
C:/OpenOfficeDev/Trunk/main/solenv/gbuild/LinkTarget.mk:126: recipe for
target
'/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o'
failed
make: ***
[/cygdrive/c/OpenOfficeDev/Trunk/main/solver/420/wntmsci12.pro/workdir/CxxObject/svl/source/numbers/zformat.o]
Error 2

dmake: Error code 2, while making 'all'

1 module(s):
svl
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/svl/prj

When you have fixed the errors in that module you can resume the build
by running:

build --all:svl
==

The build system knows the failure is potentially retriable. It tells me
exactly what to type to do the retry. WHY can't it just retry itself,
without needing my fingers on the keyboard?

On 2/2/2016 8:10 AM, Patricia Shanahan wrote:

OpenGrok looks and sounds like something I should learn about.

I think my next step is to look into the state of python. Matters may
have been complicated because I did a "dmake clean" after changing my
configure parameters to use a 32 bit JDK, before continuing the steps
from configure on.

There may be a pause - I have some non-programming stuff to do today and
tomorrow morning.

Thanks for all the help. Posting immediately on hitting a problem is
definitely getting faster progress than when I tried to puzzle things
out for myself first.

On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:

OpenGrok[1] tells me the pyversion.mk file is in main/python; through
building it would get delivered to main/solver/... and found by pyuno.
Did
python not build before pyuno did? pyuno/prj/build.lst lists a dependency
on python when PYTHON is defined[2]:

bgpupyuno : stoc cpputools cppuhelper bridges tools PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the
python
module isn't getting built first, you can force it to build first through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd ../instsetoo_native
build --all -P2 -- -P2

References:
[1]
http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk

[2]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst

On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan wrote:

Thanks. Now I get to:

=
Building module pyuno
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module

mkout -- version: 1.8
dmake: makefile.mk: line 56: Error: -- Include file pyversion.mk, not
found

On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:

For me, main/icu fails to build on Windows about 50% of the time for no
apparent reason; I've begun to think it's some sort of build race
condition
within that module. I haven't seen the buildbots fail there, and nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd ../instsetoo_native
build --all -P2 -- -P2

On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan wrote:

Good. My latest error is:

NMAKE : fatal error U1073: don't know how to make
'".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake: Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'

I am hoping after this is all done to add a section on gotchas and
their
symptoms to the step-by-step guide. That may save future new
developers
some time.

On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:

I've documented this gotcha on both

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step

and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan
wrote:

Thanks.

On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:

According to

RE: Building on Windows

2016-02-02 Thread Dennis E. Hamilton

The line-ending business is a mess.

The normal approach with SVN and Tortoise SVN is to set the system to bring 
platform-dependent line breaks to the working folder on check-out and updates 
and to use the standard on-repository (LF = NL, no CR) on check-ins.  This is 
by file type (wildcard) because it must be used only on text files, using the 
[auto-prop] option svn:eol-style=native.  (Text file names with no file 
extensions are not helpful in that respect, as they have to be individually 
named in the svn config.)

The pain is that this appears to be a global setting for SVN and Tortoise SVN.  
You set the svn:eol-style on individual file types in the [auto-props] section 
of the SVN config file, and have the enable-auto-props option set in 
[miscellany].

You can choose to use the on-repository form in the working folder.  The 
problem is that if you use Windows tools (Visual Studio, Visual Code, jEdit, 
whatever), you have to ensure that they use the same convention when they 
*save* files into the working folder.  

The better Windows development tools are ecumenical about what they accept, not 
being confused with either CRLF or LF (NL) alone.  And some can be controlled 
in what they produce.  The problem is using multiple repositories with 
different approaches.

 - Dennis

> -Original Message-
> From: Patricia Shanahan [mailto:p...@acm.org]
> Sent: Tuesday, February 2, 2016 16:37
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
> On 2/2/2016 4:34 PM, Greg Bullock wrote:
> >
> > On 2/1/2016 3:33 PM, Patricia Shanahan wrote:
> ...
> >> Thanks for looking into it. It appears to probably be, ultimately, an
> >> issue with TortoiseSVN mangling line endings. I am redoing the
> >> checkout using Cygwin's command line svn. Once that is done, I'll
> copy
> >> over a few things from the old tree, and try again from autoconf on.
> >>
> >> Patricia
> >
> > I know you've already moved on to cygwin's command line svn, but for
> > completeness: I believe TortoiseSVN lets you set options for whether
> and
> > how line endings should be handled on checkout.
> 
> I found some information about that, but it was not clear how to set
> "don't mess with the endings at all" for an entire source tree.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: Building on Windows

2016-02-02 Thread Dennis E. Hamilton

+1

Yep, there it is.  

Thanks Greg



> -Original Message-
> From: Greg Bullock [mailto:g...@nwra.com]
> Sent: Tuesday, February 2, 2016 18:54
> To: dev@openoffice.apache.org
> Subject: Re: Building on Windows
> 
> 
> 
> On 2/2/2016 4:37 PM, Patricia Shanahan wrote:
[ ... ]
> > I found some information about that, but it was not clear how to set
> > "don't mess with the endings at all" for an entire source tree.
> 
> I think you right-click (from File Explorer) on the top-level working
> folder and choose TortoiseSVN: Properties.
> Then click New... : EOL, and choose either As is (no specific EOL) or
> Linux (LF) -- not sure whether it makes a difference for AOO or which is
> more appropriate.
> I *think* that setting then applies to subfolders of your working
> folder.
> 
> -Greg
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


Thanks.

On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:

According to
http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
you're using a 64 bit JDK instead of a 32 bit one.

On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:


After checking out with Cygwin's svn rather than TortoiseSVN, my build
failed in "Building module bean" with the following message:

Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and object
../../wntmsci12.pro/lib/iofficebean_t1.exp
officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
function _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
unresolved externals
dmake:  Error code 96, while making '../../
wntmsci12.pro/bin/officebean.dll'


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


Thanks. Now I get to:

=
Building module pyuno
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module

mkout -- version: 1.8
dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk, not 
found





On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:

For me, main/icu fails to build on Windows about 50% of the time for no
apparent reason; I've begun to think it's some sort of build race condition
within that module. I haven't seen the buildbots fail there, and nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd ../instsetoo_native
build --all -P2 -- -P2


On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan  wrote:


Good. My latest error is:

NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'

I am hoping after this is all done to add a section on gotchas and their
symptoms to the step-by-step guide. That may save future new developers
some time.




On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:


I've documented this gotcha on both

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan  wrote:

Thanks.



On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:

According to



http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
you're using a 64 bit JDK instead of a 32 bit one.

On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:

After checking out with Cygwin's svn rather than TortoiseSVN, my build


failed in "Building module bean" with the following message:

  Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and
object
../../wntmsci12.pro/lib/iofficebean_t1.exp
officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
function
_Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
unresolved externals
dmake:  Error code 96, while making '../../
wntmsci12.pro/bin/officebean.dll'


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

OpenGrok[1] tells me the pyversion.mk file is in main/python; through
building it would get delivered to main/solver/... and found by pyuno. Did
python not build before pyuno did? pyuno/prj/build.lst lists a dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the python
module isn't getting built first, you can force it to build first through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd ../instsetoo_native
build --all -P2 -- -P2

References:
[1]
http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk
[2]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst

On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:

> Thanks. Now I get to:
>
> =
> Building module pyuno
> =
>
> Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module
>
> mkout -- version: 1.8
> dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk, not
> found
>
>
>
>
>
> On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:
>
>> For me, main/icu fails to build on Windows about 50% of the time for no
>> apparent reason; I've begun to think it's some sort of build race
>> condition
>> within that module. I haven't seen the buildbots fail there, and nobody
>> else has reported this problem.
>>
>> If this is your problem, the only fix I know is the following hack:
>>
>> cd main/icu
>>
>> then keep cleaning and rebuilding it until it builds successfully:
>>
>> rm -rf wntmsci12.pro
>> one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2
>>
>> then when it does, continue as before:
>>
>> cd ../instsetoo_native
>> build --all -P2 -- -P2
>>
>>
>> On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan  wrote:
>>
>> Good. My latest error is:
>>>
>>> NMAKE : fatal error U1073: don't know how to make
>>> '".\..\..\lib\icuin.lib"'
>>> Stop.
>>> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
>>> return code '0x2'
>>> Stop.
>>> dmake:  Error code 2, while making './
>>> wntmsci12.pro/misc/build/so_built_so_icu'
>>>
>>> I am hoping after this is all done to add a section on gotchas and their
>>> symptoms to the step-by-step guide. That may save future new developers
>>> some time.
>>>
>>>
>>>
>>>
>>> On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:
>>>
>>> I've documented this gotcha on both


 https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
 and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

 On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan 
 wrote:

 Thanks.

>
>
> On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:
>
> According to
>
>>
>>
>>
>> http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
>> you're using a 64 bit JDK instead of a 32 bit one.
>>
>> On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan 
>> wrote:
>>
>> After checking out with Cygwin's svn rather than TortoiseSVN, my build
>>
>> failed in "Building module bean" with the following message:
>>>
>>>   Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib
>>> and
>>> object
>>> ../../wntmsci12.pro/lib/iofficebean_t1.exp
>>> officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
>>> LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced
>>> in
>>> function
>>> _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
>>> ../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
>>> unresolved externals
>>> dmake:  Error code 96, while making '../../
>>> wntmsci12.pro/bin/officebean.dll'
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>>>
>>> -
>>
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>
>
 -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For

Re: Building on Windows

I've documented this gotcha on both
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan  wrote:

> Thanks.
>
>
> On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:
>
>> According to
>>
>> http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
>> you're using a 64 bit JDK instead of a 32 bit one.
>>
>> On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:
>>
>> After checking out with Cygwin's svn rather than TortoiseSVN, my build
>>> failed in "Building module bean" with the following message:
>>>
>>> Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and
>>> object
>>> ../../wntmsci12.pro/lib/iofficebean_t1.exp
>>> officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
>>> LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
>>> function
>>> _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
>>> ../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
>>> unresolved externals
>>> dmake:  Error code 96, while making '../../
>>> wntmsci12.pro/bin/officebean.dll'
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Building on Windows

For me, main/icu fails to build on Windows about 50% of the time for no
apparent reason; I've begun to think it's some sort of build race condition
within that module. I haven't seen the buildbots fail there, and nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd ../instsetoo_native
build --all -P2 -- -P2


On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan  wrote:

> Good. My latest error is:
>
> NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
> return code '0x2'
> Stop.
> dmake:  Error code 2, while making './
> wntmsci12.pro/misc/build/so_built_so_icu'
>
> I am hoping after this is all done to add a section on gotchas and their
> symptoms to the step-by-step guide. That may save future new developers
> some time.
>
>
>
>
> On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:
>
>> I've documented this gotcha on both
>>
>> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
>> and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
>>
>> On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan  wrote:
>>
>> Thanks.
>>>
>>>
>>> On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:
>>>
>>> According to


 http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
 you're using a 64 bit JDK instead of a 32 bit one.

 On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:

 After checking out with Cygwin's svn rather than TortoiseSVN, my build

> failed in "Building module bean" with the following message:
>
>  Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and
> object
> ../../wntmsci12.pro/lib/iofficebean_t1.exp
> officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
> LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
> function
> _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
> ../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
> unresolved externals
> dmake:  Error code 96, while making '../../
> wntmsci12.pro/bin/officebean.dll'
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
>
>
 -
>>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>>
>>>
>>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Building on Windows


Good. My latest error is:

NMAKE : fatal error U1073: don't know how to make '".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' : 
return code '0x2'

Stop.
dmake:  Error code 2, while making 
'./wntmsci12.pro/misc/build/so_built_so_icu'


I am hoping after this is all done to add a section on gotchas and their 
symptoms to the step-by-step guide. That may save future new developers 
some time.




On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:

I've documented this gotcha on both
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan  wrote:


Thanks.


On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:


According to

http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
you're using a 64 bit JDK instead of a 32 bit one.

On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:

After checking out with Cygwin's svn rather than TortoiseSVN, my build

failed in "Building module bean" with the following message:

 Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and
object
../../wntmsci12.pro/lib/iofficebean_t1.exp
officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
function
_Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
unresolved externals
dmake:  Error code 96, while making '../../
wntmsci12.pro/bin/officebean.dll'


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

On Tue, Feb 2, 2016 at 6:10 PM, Patricia Shanahan  wrote:

> OpenGrok looks and sounds like something I should learn about.
>
> I think my next step is to look into the state of python. Matters may have
> been complicated because I did a "dmake clean" after changing my configure
> parameters to use a 32 bit JDK, before continuing the steps from configure
> on.
>
>
Yes, I think "dmake clean" requires re-running configure, bootstrap, source
winenv.set.sh and only then build.


> There may be a pause - I have some non-programming stuff to do today and
> tomorrow morning.
>
> Thanks for all the help. Posting immediately on hitting a problem is
> definitely getting faster progress than when I tried to puzzle things out
> for myself first.
>
>
It's a pleasure, sorry it's so hard, and thank you for your perseverance
through this building nightmare.

I think Sun Microsystems really had a knack for "comedy build systems" as
someone described them. OpenJDK was similarly painful to compile,
especially when they first open-sourced it.


>
> On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:
>
>> OpenGrok[1] tells me the pyversion.mk file is in main/python; through
>> building it would get delivered to main/solver/... and found by pyuno. Did
>> python not build before pyuno did? pyuno/prj/build.lst lists a dependency
>> on python when PYTHON is defined[2]:
>>
>> bgpupyuno   :   stoc cpputools cppuhelper bridges tools PYTHON:python
>> LIBXSLT:libxslt NULL
>>
>> but earlier you posted your config.log which had this in it:
>>
>> PYTHON=''
>>
>> and I am not sure whether that's enough. If the problem is that the python
>> module isn't getting built first, you can force it to build first through
>> one of these hacks:
>> * delete the "PYTHON:" prefix to "python" from the build.lst line
>> * manually building python before resuming the build:
>> cd main/python
>> build
>> deliver
>> cd ../instsetoo_native
>> build --all -P2 -- -P2
>>
>> References:
>> [1]
>>
>> http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk
>> [2]
>>
>> http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst
>>
>> On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:
>>
>> Thanks. Now I get to:
>>>
>>> =
>>> Building module pyuno
>>> =
>>>
>>> Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module
>>>
>>> mkout -- version: 1.8
>>> dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk, not
>>> found
>>>
>>>
>>>
>>>
>>>
>>> On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:
>>>
>>> For me, main/icu fails to build on Windows about 50% of the time for no
 apparent reason; I've begun to think it's some sort of build race
 condition
 within that module. I haven't seen the buildbots fail there, and nobody
 else has reported this problem.

 If this is your problem, the only fix I know is the following hack:

 cd main/icu

 then keep cleaning and rebuilding it until it builds successfully:

 rm -rf wntmsci12.pro
 one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

 then when it does, continue as before:

 cd ../instsetoo_native
 build --all -P2 -- -P2


 On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan  wrote:

 Good. My latest error is:

>
> NMAKE : fatal error U1073: don't know how to make
> '".\..\..\lib\icuin.lib"'
> Stop.
> NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
> return code '0x2'
> Stop.
> dmake:  Error code 2, while making './
> wntmsci12.pro/misc/build/so_built_so_icu'
>
> I am hoping after this is all done to add a section on gotchas and
> their
> symptoms to the step-by-step guide. That may save future new developers
> some time.
>
>
>
>
> On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:
>
> I've documented this gotcha on both
>
>>
>>
>>
>> https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
>> and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO
>>
>> On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan 
>> wrote:
>>
>> Thanks.
>>
>>
>>>
>>> On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:
>>>
>>> According to
>>>
>>>



 http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
 you're using a 64 bit JDK instead of a 32 bit one.

 On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan 
 wrote:

 After checking out with Cygwin's svn rather than TortoiseSVN, my
 build

 failed in "Building module bean" with the following message:

>
>Creating library

Re: Building on Windows


OpenGrok looks and sounds like something I should learn about.

I think my next step is to look into the state of python. Matters may 
have been complicated because I did a "dmake clean" after changing my 
configure parameters to use a 32 bit JDK, before continuing the steps 
from configure on.


There may be a pause - I have some non-programming stuff to do today and 
tomorrow morning.


Thanks for all the help. Posting immediately on hitting a problem is 
definitely getting faster progress than when I tried to puzzle things 
out for myself first.


On 2/2/2016 6:39 AM, Damjan Jovanovic wrote:

OpenGrok[1] tells me the pyversion.mk file is in main/python; through
building it would get delivered to main/solver/... and found by pyuno. Did
python not build before pyuno did? pyuno/prj/build.lst lists a dependency
on python when PYTHON is defined[2]:

bgpupyuno   :   stoc cpputools cppuhelper bridges tools PYTHON:python
LIBXSLT:libxslt NULL

but earlier you posted your config.log which had this in it:

PYTHON=''

and I am not sure whether that's enough. If the problem is that the python
module isn't getting built first, you can force it to build first through
one of these hacks:
* delete the "PYTHON:" prefix to "python" from the build.lst line
* manually building python before resuming the build:
cd main/python
build
deliver
cd ../instsetoo_native
build --all -P2 -- -P2

References:
[1]
http://opengrok.adfinis-sygroup.org/source/search?qpyversion.mk==aoo-trunk
[2]
http://opengrok.adfinis-sygroup.org/source/xref/aoo-trunk/main/pyuno/prj/build.lst

On Tue, Feb 2, 2016 at 4:21 PM, Patricia Shanahan  wrote:


Thanks. Now I get to:

=
Building module pyuno
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/pyuno/source/module

mkout -- version: 1.8
dmake:  makefile.mk:  line 56:  Error: -- Include file pyversion.mk, not
found





On 2/2/2016 4:18 AM, Damjan Jovanovic wrote:


For me, main/icu fails to build on Windows about 50% of the time for no
apparent reason; I've begun to think it's some sort of build race
condition
within that module. I haven't seen the buildbots fail there, and nobody
else has reported this problem.

If this is your problem, the only fix I know is the following hack:

cd main/icu

then keep cleaning and rebuilding it until it builds successfully:

rm -rf wntmsci12.pro
one of: dmake / build -P2 / build -- -P2 / build -P2 -- -P2

then when it does, continue as before:

cd ../instsetoo_native
build --all -P2 -- -P2


On Tue, Feb 2, 2016 at 2:00 PM, Patricia Shanahan  wrote:

Good. My latest error is:


NMAKE : fatal error U1073: don't know how to make
'".\..\..\lib\icuin.lib"'
Stop.
NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\nmake.exe' :
return code '0x2'
Stop.
dmake:  Error code 2, while making './
wntmsci12.pro/misc/build/so_built_so_icu'

I am hoping after this is all done to add a section on gotchas and their
symptoms to the step-by-step guide. That may save future new developers
some time.




On 2/2/2016 3:32 AM, Damjan Jovanovic wrote:

I've documented this gotcha on both



https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step
and https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO

On Tue, Feb 2, 2016 at 10:29 AM, Patricia Shanahan 
wrote:

Thanks.




On 2/1/2016 11:50 PM, Damjan Jovanovic wrote:

According to





http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
you're using a 64 bit JDK instead of a 32 bit one.

On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan 
wrote:

After checking out with Cygwin's svn rather than TortoiseSVN, my build

failed in "Building module bean" with the following message:


   Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib
and
object
../../wntmsci12.pro/lib/iofficebean_t1.exp
officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced
in
function
_Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
unresolved externals
dmake:  Error code 96, while making '../../
wntmsci12.pro/bin/officebean.dll'


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-



To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org






-
To unsubscribe, e-mail:

Re: Building on Windows

2016-02-02 Thread Greg Bullock




On 2/2/2016 4:37 PM, Patricia Shanahan wrote:

On 2/2/2016 4:34 PM, Greg Bullock wrote:


On 2/1/2016 3:33 PM, Patricia Shanahan wrote:

...

Thanks for looking into it. It appears to probably be, ultimately, an
issue with TortoiseSVN mangling line endings. I am redoing the
checkout using Cygwin's command line svn. Once that is done, I'll copy
over a few things from the old tree, and try again from autoconf on.

Patricia


I know you've already moved on to cygwin's command line svn, but for
completeness: I believe TortoiseSVN lets you set options for whether and
how line endings should be handled on checkout.


I found some information about that, but it was not clear how to set
"don't mess with the endings at all" for an entire source tree.


I think you right-click (from File Explorer) on the top-level working 
folder and choose TortoiseSVN: Properties.
Then click New... : EOL, and choose either As is (no specific EOL) or 
Linux (LF) -- not sure whether it makes a difference for AOO or which is 
more appropriate.

I *think* that setting then applies to subfolders of your working folder.

-Greg

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows




On 1/31/2016 6:36 PM, Patricia Shanahan wrote:

Now I'm stuck. I got through configure, with warnings. My build attempt
failed with:

$ build --all
build -- version: 275224


=
Building module solenv
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv

/cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
$':\r': command not found
mkout -- version: 1.8


The perl module mkout.pl starts with:

:
eval 'exec perl -wS $0 ${1+"$@"}'
if 0;


My Perl is very rusty. Can anyone translate? Especially, the initial 
line with just a ":" confuses both me and the build.


Patricia


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-01 Thread j.nitsc...@ok.de

On Mon, 1 Feb 2016 14:08:06 -0800 Patricia Shanahan wrote:
>
>
> On 2/1/2016 12:04 PM, Patricia Shanahan wrote:
>>
>>
>> On 1/31/2016 6:36 PM, Patricia Shanahan wrote:
>>> Now I'm stuck. I got through configure, with warnings. My build attempt
>>> failed with:
>>>
>>> $ build --all
>>> build -- version: 275224
>>>
>>>
>>> =
>>> Building module solenv
>>> =
>>>
>>> Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv
>>>
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
>>> $':\r': command not found
>>> mkout -- version: 1.8
>>
>> The perl module mkout.pl starts with:
>>
>> :
>> eval 'exec perl -wS $0 ${1+"$@"}'
>>  if 0;
>>
>>
>> My Perl is very rusty. Can anyone translate? Especially, the initial
>> line with just a ":" confuses both me and the build.
>
> I took my problem to StackOverflow. See
> http://stackoverflow.com/a/35140265/1798593
>
> I worked around it by setting igncr in my Cygwin bash SHELLOPTS, and
> the build is now building.
>
> Patricia
interesting, how did you checkout the source?

I remember TortoiseSVN converted unix line endings to windows style
unless told otherwise. The original git-scm asks on installation how to
treat line endings. No idea how the cygwin subverion and git packages
behave.

You might run into other unexpected problems due line endings. (e.g.
scripts replacing \n with \r\n for windows)
I would checkout the source again.



signature.asc
Description: OpenPGP digital signature

Re: Building on Windows




On 2/1/2016 12:04 PM, Patricia Shanahan wrote:



On 1/31/2016 6:36 PM, Patricia Shanahan wrote:

Now I'm stuck. I got through configure, with warnings. My build attempt
failed with:

$ build --all
build -- version: 275224


=
Building module solenv
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv

/cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
$':\r': command not found
mkout -- version: 1.8


The perl module mkout.pl starts with:

:
eval 'exec perl -wS $0 ${1+"$@"}'
 if 0;


My Perl is very rusty. Can anyone translate? Especially, the initial
line with just a ":" confuses both me and the build.


I took my problem to StackOverflow. See 
http://stackoverflow.com/a/35140265/1798593


I worked around it by setting igncr in my Cygwin bash SHELLOPTS, and the 
build is now building.


Patricia


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


On 2/1/2016 2:41 PM, j.nitsc...@ok.de wrote:

On Mon, 1 Feb 2016 14:08:06 -0800 Patricia Shanahan wrote:



On 2/1/2016 12:04 PM, Patricia Shanahan wrote:



On 1/31/2016 6:36 PM, Patricia Shanahan wrote:

Now I'm stuck. I got through configure, with warnings. My build attempt
failed with:

$ build --all
build -- version: 275224


=
Building module solenv
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv

/cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
$':\r': command not found
mkout -- version: 1.8


The perl module mkout.pl starts with:

:
eval 'exec perl -wS $0 ${1+"$@"}'
  if 0;


My Perl is very rusty. Can anyone translate? Especially, the initial
line with just a ":" confuses both me and the build.


I took my problem to StackOverflow. See
http://stackoverflow.com/a/35140265/1798593

I worked around it by setting igncr in my Cygwin bash SHELLOPTS, and
the build is now building.

Patricia

interesting, how did you checkout the source?

I remember TortoiseSVN converted unix line endings to windows style
unless told otherwise. The original git-scm asks on installation how to
treat line endings. No idea how the cygwin subverion and git packages
behave.

You might run into other unexpected problems due line endings. (e.g.
scripts replacing \n with \r\n for windows)
I would checkout the source again.



Thanks. I did use TortoiseSVN, so that is probably the problem.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


On 2/1/2016 7:00 AM, Damjan Jovanovic wrote:

On Mon, Feb 1, 2016 at 4:46 PM, Patricia Shanahan  wrote:


On 2/1/2016 4:34 AM, Regina Henschel wrote:


Hi Patricia,

Patricia Shanahan schrieb:


Now I'm stuck. I got through configure, with warnings.



Can you please be more specific about the warnings?

Are you sure, you start building in instsetoo_native ?



I've posted a message in this thread with config.log attached. Here is the
prompt, including current directory, from my attempt to run build. I did my
SVN checkout into /cygdrive/c/OpenOfficeDev/Trunk

Patricia@Jan2014Desktop
/cygdrive/c/OpenOfficeDev/Trunk/main/instsetoo_native
$ build --all

Thanks,

Patricia



Windows is probably the worst platform to build on: it's the slowest and
apparently the most problematic :-(.


64-bit Windows is one of the commonest platforms that can be used for 
software development. The problems with building AOO on it may 
discourage a lot of potential developers.




Nothing seems obviously wrong so far. That perl file your build breaks on
wasn't changed since 2012. Later I will compare your ./configure options
with my own that works. In the meanwhile please post the entire sequence of
commands you ran, from autoconf onwards. You could also "dmake clean" after
you "source winenv...", then start again from ./configure.


Thanks for looking into it. It appears to probably be, ultimately, an 
issue with TortoiseSVN mangling line endings. I am redoing the checkout 
using Cygwin's command line svn. Once that is done, I'll copy over a few 
things from the old tree, and try again from autoconf on.


Patricia

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-01 Thread Damjan Jovanovic

On Mon, Feb 1, 2016 at 1:49 PM, Patricia Shanahan  wrote:

>
>
> On 1/31/2016 11:59 PM, Damjan Jovanovic wrote:
>
>> On Mon, Feb 1, 2016 at 4:36 AM, Patricia Shanahan  wrote:
>>
>> Now I'm stuck. I got through configure, with warnings. My build attempt
>>> failed with:
>>>
>>> $ build --all
>>> build -- version: 275224
>>>
>>>
>>> =
>>> Building module solenv
>>> =
>>>
>>> Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv
>>>
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
>>> $':\r':
>>> command not found
>>> mkout -- version: 1.8
>>> /usr/bin/bash: C:/OpenOfficeDev/Trunk/main/solenv/
>>> wntmsci12.pro/inc/myworld.mk: No such file or directory
>>> dmake:  Error code 1, while making
>>> '/cygdrive/C/OpenOfficeDev/Trunk/main/solenv/
>>> wntmsci12.pro/inc/myworld.mk'
>>>
>>> 1 module(s):
>>>  solenv
>>> need(s) to be rebuilt
>>>
>>> Reason(s):
>>>
>>> ERROR: error 65280 occurred while making
>>> /cygdrive/c/OpenOfficeDev/Trunk/main/solenv
>>>
>>> When you have fixed the errors in that module you can resume the build by
>>> running:
>>>
>>>  build --all:solenv
>>>
>>> Any advice on e.g. configure warnings that are likely to be significant?
>>>
>>>
>>> A Perl problem of some kind?
>>
>> Please post your main/config.log and see if the "perl" command works.
>>
>
> A perl "hello, world" runs in the Cygwin terminal window I used for the
> build attempt. I am attaching my config.log. The call was:
>
> SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
> ./configure \
> --with-frame-home="$SDK_PATH" \
> --with-psdk-home="$SDK_PATH" \
> --with-midl-path="$SDK_PATH/bin" \
> --with-directx-home="C:/Program Files (x86)/Microsoft DirectX SDK
> (June 2010)" \
> --with-ant-home="/cygdrive/c/ant" \
>
> --with-dmake-url="
> http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2; \
>
> --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz;
> \
> --enable-pch \
> --disable-atl \
> --disable-activex \
> --without-junit \
> --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0_67"
>
> Thanks for any advice,
>
> Patricia
>
>
Why do you have both PROGRA~1 and PROGRA~2 paths (I presume these are
"Program Files" and "Program Files (x86)")? Are you building on Win64? We
don't have a Win64 version of AOO, so it's possible (I'm not sure) that AOO
doesn't even compile on Win64.

PATH: /cygdrive/c/PROGRA~1/Java/JDK18~1.0_7/bin
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/Common7/IDE
PATH: /cygdrive/c/PROGRA~1/MICROS~2/Windows/v7.0/bin
PATH: /cygdrive/c/Windows/MICROS~1.NET/FRAMEW~1/V20~1.507
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin

Otherwise my own ./configure options differ from yours as follows:
* Build is done in a 32 bit virtual machine
* I used --disable-directx instead of your --with-directx-home=...
* I also had --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual
Studio 9.0/VC
* I also had
--with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5

Damjan

Re: Building on Windows

2016-02-01 Thread Regina Henschel


Hi Patricia,

Patricia Shanahan schrieb:

Now I'm stuck. I got through configure, with warnings.


Can you please be more specific about the warnings?

Are you sure, you start building in instsetoo_native ?

Kind regards
Regina




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows


On 2/1/2016 8:34 AM, Damjan Jovanovic wrote:

On Mon, Feb 1, 2016 at 1:49 PM, Patricia Shanahan  wrote:




On 1/31/2016 11:59 PM, Damjan Jovanovic wrote:


On Mon, Feb 1, 2016 at 4:36 AM, Patricia Shanahan  wrote:

Now I'm stuck. I got through configure, with warnings. My build attempt

failed with:

$ build --all
build -- version: 275224


=
Building module solenv
=

Entering /cygdrive/c/OpenOfficeDev/Trunk/main/solenv

/cygdrive/c/OpenOfficeDev/Trunk/main/solenv/bin/mkout.pl: line 1:
$':\r':
command not found
mkout -- version: 1.8
/usr/bin/bash: C:/OpenOfficeDev/Trunk/main/solenv/
wntmsci12.pro/inc/myworld.mk: No such file or directory
dmake:  Error code 1, while making
'/cygdrive/C/OpenOfficeDev/Trunk/main/solenv/
wntmsci12.pro/inc/myworld.mk'

1 module(s):
  solenv
need(s) to be rebuilt

Reason(s):

ERROR: error 65280 occurred while making
/cygdrive/c/OpenOfficeDev/Trunk/main/solenv

When you have fixed the errors in that module you can resume the build by
running:

  build --all:solenv

Any advice on e.g. configure warnings that are likely to be significant?


A Perl problem of some kind?


Please post your main/config.log and see if the "perl" command works.



A perl "hello, world" runs in the Cygwin terminal window I used for the
build attempt. I am attaching my config.log. The call was:

SDK_PATH="/cygdrive/c/Program Files/Microsoft SDKs/Windows/v7.0"
./configure \
 --with-frame-home="$SDK_PATH" \
 --with-psdk-home="$SDK_PATH" \
 --with-midl-path="$SDK_PATH/bin" \
 --with-directx-home="C:/Program Files (x86)/Microsoft DirectX SDK
(June 2010)" \
 --with-ant-home="/cygdrive/c/ant" \

--with-dmake-url="
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2; \

--with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz;
\
 --enable-pch \
 --disable-atl \
 --disable-activex \
 --without-junit \
 --with-jdk-home="/cygdrive/c/Program Files/Java/jdk1.7.0_67"

Thanks for any advice,

Patricia



Why do you have both PROGRA~1 and PROGRA~2 paths (I presume these are
"Program Files" and "Program Files (x86)")? Are you building on Win64? We
don't have a Win64 version of AOO, so it's possible (I'm not sure) that AOO
doesn't even compile on Win64.

PATH: /cygdrive/c/PROGRA~1/Java/JDK18~1.0_7/bin
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/Common7/IDE
PATH: /cygdrive/c/PROGRA~1/MICROS~2/Windows/v7.0/bin
PATH: /cygdrive/c/Windows/MICROS~1.NET/FRAMEW~1/V20~1.507
PATH: /cygdrive/c/PROGRA~2/MICROS~1.0/VC/bin

Otherwise my own ./configure options differ from yours as follows:
* Build is done in a 32 bit virtual machine
* I used --disable-directx instead of your --with-directx-home=...
* I also had --with-cl-home=/cygdrive/c/Program Files/Microsoft Visual
Studio 9.0/VC
* I also had
--with-csc-path=/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5

Damjan



I don't have a working 32-bit machine. When is AOO going to catch up 
with current memory sizes? I've already had to downgrade to 32-bit Cygwin.


I'll try the rest of the changes first, but having to go virtual to 
build would probably kill my attempts to do AOO development on Windows. 
I might try to do some work on one of my Linux boxes instead, but it 
would affect my productivity. They only have small screens, relatively 
small memories (still too big for a 32 bit OS), and don't support 
Carbonite for backup. Also, I would like to be able to look at equation 
display on Windows, and for that I need to do Windows builds.


Thanks,

Patricia

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

After checking out with Cygwin's svn rather than TortoiseSVN, my build 
failed in "Building module bean" with the following message:


   Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and 
object ../../wntmsci12.pro/lib/iofficebean_t1.exp
officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error 
LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in 
function _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1 
unresolved externals

dmake:  Error code 96, while making '../../wntmsci12.pro/bin/officebean.dll'

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Building on Windows

2016-02-01 Thread Damjan Jovanovic

According to
http://stackoverflow.com/questions/19641685/java-jni-jawt-error-unresolved-external-symbol-imp-jawt-getawt8
you're using a 64 bit JDK instead of a 32 bit one.

On Tue, Feb 2, 2016 at 9:40 AM, Patricia Shanahan  wrote:

> After checking out with Cygwin's svn rather than TortoiseSVN, my build
> failed in "Building module bean" with the following message:
>
>Creating library ../../wntmsci12.pro/lib/iofficebean_t1.lib and object
> ../../wntmsci12.pro/lib/iofficebean_t1.exp
> officebean.lib(com_sun_star_comp_beans_LocalOfficeWindow.obj) : error
> LNK2019: unresolved external symbol __imp__JAWT_GetAWT@8 referenced in
> function _Java_com_sun_star_comp_beans_LocalOfficeWindow_getNativeWindow@8
> ../../wntmsci12.pro/bin/officebean.dll : fatal error LNK1120: 1
> unresolved externals
> dmake:  Error code 96, while making '../../
> wntmsci12.pro/bin/officebean.dll'
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>

Re: Building on Windows