[dev] Re: Build breaks in setup-native

[Hans-Joachim Lankenau]

hi!

i found that
http://hg.services.openoffice.org/cws/ause130/rev/b4abd2828ea5
fixed this problem for me. seems to be connected with the special 
treatment of the INCLUDE variable and the length of it.


tschau...

ause

Regina Henschel wrote:

Hi,

I want to build CWS aw080 for Windows, but it breaks with error:

Compiling: setup_native/wntmsci12.pro/misc/cl : Command line error D8038
: invalid argument '-I. -I../../../../wntmsci12.pro/inc/reg64msi
-I../inc -I../../../../inc/pch -I../../../../inc -I../../../../WIN/inc
-I../../../../wntmsci12.pro/inc -I.
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solver/300/wntmsci12.pro/inc
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solver/300/wntmsci12.pro/inc/external
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solver/300/wntmsci12.pro/inc
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solenv/wntmsci12/inc
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solenv/inc
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/res
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solver/300/wntmsci12.pro/inc
-Ic:/PROGRA~1/Java/JDK16~1.0_1/include/win32
-Ic:/PROGRA~1/Java/JDK16~1.0_1/include
-Ic:/PROGRA~1/MI2578~1/Windows/v6.1/include
-Ic:/PROGRA~1/MICROS~1.0/VC/include -Ic:/PROGRA~1/MIAF9D~2/include
-Ic:/PROGRA~1/MIAF9D~2/include
-Ie:/SoftwareArchiv/OOoDownloads/CWSaw080source/aw080-bc14062ba090/solver/300/wntmsci12.pro/inc/offuh
-I. -I../../../../res -I.'
dmake: Error code 2, while making
'../../../../wntmsci12.pro/slo/reg64msi_version.obj'

How can I solve it?

My configure has been:
./configure \
--with-directx-home="/cygdrive/c/Programme/Microsoft DirectX SDK (March
2009)" \
--with-cl-home="/cygdrive/c/Programme/Microsoft Visual Studio 9.0/VC" \
--disable-activex \
--disable-build-mozilla \
--disable-nss-module \
--disable-atl \
--with-frame-home="/cygdrive/c/Programme/Microsoft SDKs/Windows/v6.1" \
--with-psdk-home="/cygdrive/c/Programme/Microsoft SDKs/Windows/v6.1" \
--with-midl-path="/cygdrive/c/Programme/Microsoft SDKs/Windows/v6.0A/bin" \
--with-asm-home="/cygdrive/c/Programme/Microsoft Visual Studio
9.0/VC/bin" \
--with-jdk-home="/cygdrive/c/Programme/Java/jdk1.6.0_14" \
--with-csc-path="/cygdrive/c/Windows/Microsoft.NET/Framework/v3.5" \
--with-ant-home=/ant \
--with-use-shell=bash

kind regards
Regina

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




--
-
To unsubscribe send email to dev-unsubscr...@openoffice.org
For additional commands send email to sy...@openoffice.org
with Subject: help

[dev] Re: [www-dev] Re: building svl failed

[Hans-Joachim Lankenau]

hi!

more below...

Yan Wu wrote:


hmm, still have no idea, the call to cpp/rscpp is not shown...
please try the following:
first apply the attached patch (to give -verbose flag to rsc)
then rebuild rsc:
  (cd rsc&&  rm -r wntmsci*&&  build debug=t&&  deliver)
then try again, it should now print the arguments that don't work


The call to cpp/rsccpp is still not shown after applying the patch and
rebuilding rsc. The error log is:


$ make -r
[ build DEP ] SRS:svl/res
R=/cygdrive/f&&  S=$R/DEV300_m100&&  O=$S/solver/300/wntmsci12.pro&&  W=$O/workd
ir&&   mkdir -p $W/Dep/SrsTarget/svl/&&  cat $W/Dep/SrsPartTarget/svl/source/mis
c/mediatyp.src.d $W/Dep/SrsPartTarget/svl/source/items/cstitem.src.d>  $W/Dep/Sr
sTarget/svl/res.d
R=f:/&&  O=f:/DEV300_m100/solver/300/wntmsci12.pro&&  W=f:/DEV300_m100/solver/30
0/wntmsci12.pro/workdir&&  S=f:/DEV300_m100&&   $O/bin/makedepend.exe -I. -I$O/i
nc/stl -I$O/inc/external -I$O/inc -I$S/solenv/wntmsci12/inc -I$S/solenv/inc -I$S
/res -I$O/inc/stl -Id:/OOoEnv/JDK16~1.0_1/include/win32 -Id:/OOoEnv/JDK16~1.0_1/
include -Ic:/PROGRA~1/MI2578~1/Windows/v6.1/include -Ic:/PROGRA~1/MICROS~1.0/VC/
include -Ic:/PROGRA~1/MICROS~1.0SD/include -Ic:/PROGRA~1/MICROS~1.0SD/include  -
I$W/inc -I$S/svl/source/inc -I$S/svl/inc/ -I$S/svl/inc/svl  -DBOOST_MEM_FN_ENABL
E_CDECL -DCPPU_ENV=msci -DCUI -DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_LAYOUT=0 -
DENABLE_LAYOUT_EXPERIMENTAL=0 -DFULL_DESK -DINTEL -DM1500 -DMSC -DNDEBUG -DNT351
  -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPRODUCT -DPRODUCT_FULL -DSOLAR_JAVA 
-DSTLPORT_
VERSION=400 -DSUPD=300 -DVCL -DWIN32 -DWINVER=0x0500 -DWNT -D_CRT_NONSTDC_NO_DEP
RECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_MT -D_REENT
RANT -D_WIN32_IE=0x0500 -D_X86_=1 $S/svl/source/misc/mediatyp.src -f - | awk -f
$S/solenv/gbuild/processdeps.awk -v OBJECTFILE=$W/SrsPartTarget/svl/source/misc/
mediatyp.src -v OUTDIR=$O/ -v WORKDIR=$W/ -v SRCDIR=$S/ -v REPODIR=$R/>  $W/Dep/
SrsPartTarget/svl/source/misc/mediatyp.src.d
R=f:/&&  O=f:/DEV300_m100/solver/300/wntmsci12.pro&&  W=f:/DEV300_m100/solver/30
0/wntmsci12.pro/workdir&&  S=f:/DEV300_m100&&   mkdir -p $W/SrsPartTarget/svl/so
urce/misc/&&  RESPONSEFILE=`mktemp --tmpdir=C:/cygwin/tmp -t gbuild.XX`&&  e
cho "-s -verbose -I. -I$O/inc/stl -I$O/inc/external -I$O/inc -I$S/solenv/wntmsci
12/inc -I$S/solenv/inc -I$S/res -I$O/inc/stl -Id:/OOoEnv/JDK16~1.0_1/include/win
32 -Id:/OOoEnv/JDK16~1.0_1/include -Ic:/PROGRA~1/MI2578~1/Windows/v6.1/include -
Ic:/PROGRA~1/MICROS~1.0/VC/include -Ic:/PROGRA~1/MICROS~1.0SD/include -Ic:/PROGR
A~1/MICROS~1.0SD/include  -I$W/inc -I$S/svl/source/inc -I$S/svl/inc/ -I$S/svl/in
c/svl  -I$S/svl/source/misc/ -DBOOST_MEM_FN_ENABLE_CDECL -DCPPU_ENV=msci -DCUI -
DENABLE_GRAPHITE -DENABLE_GTK -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -
DFULL_DESK -DINTEL -DM1500 -DMSC -DNDEBUG -DNT351 -DOPTIMIZE -DOSL_DEBUG_LEVEL=0
  -DPRODUCT -DPRODUCT_FULL -DSOLAR_JAVA -DSTLPORT_VERSION=400 -DSUPD=300 -DVCL 
-D
WIN32 -DWINVER=0x0500 -DWNT -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SW
PRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_MT -D_REENTRANT -D_WIN32_IE=0x0500 -D_X86_
=1 -fp=$W/SrsPartTarget/svl/source/misc/mediatyp.src $S/svl/source/misc/mediatyp
.src">  ${RESPONSEFILE}&&  SOLARBINDIR=$O/bin $O/bin/rsc.exe -presponse @${RESPO
NSEFILE}&&  rm -rf ${RESPONSEFILE}
Preprocessor commandline:  -I. -If:/DEV300_m100/solver/300/wntmsci12.pro/inc/stl
  -If:/DEV300_m100/solver/300/wntmsci12.pro/inc/external 
-If:/DEV300_m100/solver/
300/wntmsci12.pro/inc -If:/DEV300_m100/solenv/wntmsci12/inc -If:/DEV300_m100/sol
env/inc -If:/DEV300_m100/res -If:/DEV300_m100/solver/300/wntmsci12.pro/inc/stl -
Id:/OOoEnv/JDK16~1.0_1/include/win32 -Id:/OOoEnv/JDK16~1.0_1/include -Ic:/PROGRA
~1/MI2578~1/Windows/v6.1/include -Ic:/PROGRA~1/MICROS~1.0/VC/include -Ic:/PROGRA
~1/MICROS~1.0SD/include -Ic:/PROGRA~1/MICROS~1.0SD/include -If:/DEV300_m100/solv
er/300/wntmsci12.pro/workdir/inc -If:/DEV300_m100/svl/source/inc -If:/DEV300_m10
0/svl/inc/ -If:/DEV300_m100/svl/inc/svl -If:/DEV300_m100/svl/source/misc/ -DBOOS
T_MEM_FN_ENABLE_CDECL -DCPPU_ENV=msci -DCUI -DENABLE_GRAPHITE -DENABLE_GTK -DENA
BLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0 -DFULL_DESK -DINTEL -DM1500 -DMSC -D
NDEBUG -DNT351 -DOPTIMIZE -DOSL_DEBUG_LEVEL=0 -DPRODUCT -DPRODUCT_FULL -DSOLAR_J
AVA -DSTLPORT_VERSION=400 -DSUPD=300 -DVCL -DWIN32 -DWINVER=0x0500 -DWNT -D_CRT_
NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE
-D_MT -D_REENTRANT -D_WIN32_IE=0x0500 -D_X86_=1 f:/DEV300_m100/svl/source/misc/m
ediatyp.src C:\Documents and Settings\wuyan\174.tmp

i bet it's breaking because of $T(E)MP containing a path with blanks.


Preprocessor startline:  f:/DEV300_m100/solver/300/wntmsci12.pro/bin/rscpp @C:\D
ocuments and Settings\wuyan\175.tmp
cpp: line 0, Error: Too many file arguments.  Usage: cpp [input [output]]
@C:\Documents: Invalid argument
cpp: line 0, Error: Can't open input file "@C:\Documents"

would explain this for example...


Error start

Re: [dev] icu build problem on Windows 7

[Hans-Joachim Lankenau]

hi!

this change helped here:

 snip 
--- icu/createmak.cfg 2010-01-18 13:09:43.469543400 +0100
+++ createmak.cfg   2010-03-23 13:47:34.120672000 +0100
@@ -2,10 +2,7 @@
 SOURCE=
 InputPath=
 "" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
-   <
-<<

 [Deps]
 SOURCE=.\.
 snip 

tschau...

ause

Martin Hollmichel wrote:

Hi,

during the setup of the new OpenOffice.org build machine I have this
poblem:

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

tempfile.bat
1 file(s) copied.
i18n.mak(1046) : fatal error U1054: cannot create inline file
'tempfile.bat'
Stop.
NMAKE : fatal error U1077: 'E:\solver\r\msvc9p\bin\nmake.exe' : return
code '0x2'
Stop.

looks like that there's a timing problem since a couple of tempfile.bat
are created and executed and in repeated builds the nmake stops at
different stages.

the Windows7 version is a 64bit one and running in a VirtualBox, anybody
also experienced this problem ?

Martin


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





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

Re: [dev] Build fails with Cygwin 1.7.1

[Hans-Joachim Lankenau - Sun Germany - ham02 - Hamburg]

hi!

see http://qa.openoffice.org/issues/show_bug.cgi?id=108254 and cws 
aus112 (http://hg.services.openoffice.org/cws/aus112/).


tschau...

ause

On 01/11/10 15:15, Daniel B. wrote:

Hi,

did anyone on this list manage to complete an OOo build using the new
Cygwin version 1.7.1?

I tried building OOO310m19, which was working for me using Cygwin
1.5.25, and after the update it fails. Looks like no files are copied
to the solver directory which leads to an error while making the
soltools module because the file stlport_vc71.lib could not be found
by the linker. We dug a little deeper and found out that the problem
lies in the deliver.pl script which indeed does not copy any files to
the solver directory because copy_if_newer always returns 0. To make a
long story short the ultimate cause of the problem seems to lie in the
following hack for Cygwin on line 113 of deliver.pl:

if ($^O ne 'cygwin') {  # iz59477 - cygwin needes a dot
"." at the end of filenames to disable
  $maybedot = '';   # some .exe transformation magic.
} else {
  $maybedot = '.';
}


The explanation why this hack is there can be found in
http://qa.openoffice.org/issues/show_bug.cgi?id=59477. In short,
appending a dot to the filenames in some cases prevents Cygwin from
erroneously thinking files are there which really aren't (because the
file "foo" and "foo.exe" are in some cases treated as the same file by
Cygwin). Sadly, it looks like this hack does no longer work in Cygwin
1.7.x (as has also been noted by tml in the last comment for issue
59477), which I gues means that OOo can't be build with Cygwin 1.7.x
at the moment.
I tried just removing the hack but since the underlying problem in
Cygwin with the ".exe transformation magic" still exists this doesn't
fix the problem.

So, just a heads up for anyone trying to use the new Cygwin version.
Or maybe someone already has a solution for this?

I will also open a new OOo issue for this problem.


Regards,
Daniel

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




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

Re: [dev] changing the patch mechanism for external sources

[Hans-Joachim Lankenau]

hi!
Stephan Bergmann wrote:

On 01/23/09 16:10, Hans-Joachim Lankenau wrote:

with the changes done in the cws ause099, each change now will reside in
 its own patch. for the local module makefiles, the only visible change
is PATCH_FILE_NAME -> PATCH_FILES. this variable now hold the list (and
apply prder) of the existing patches.


In some cases, logically coherent sets of modifications to some source 
evolve over time (e.g., more instances of #pragma GCC system_header in 
stlport/STLport-4.5.patch over time, as later GCC versions produce more 
extensive diagnostics).  Is it still possible to keep those together in 
a single patch?
sure. but strictly speaking, it's removing the old patch and appending a 
new one at the end of the PATCH_FILES list. with all consequences...


the new "dmake create_patch" doesn't support modifying existing patches.

tschau...

ause

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

[dev] changing the patch mechanism for external sources

[Hans-Joachim Lankenau]

hi!

in the current scenario, there is only one active patch per source
tarball which has to contain all required changes for the build. as
discussed in issue 40246, this may lead to duplication and hard to
maintain patches.

with the changes done in the cws ause099, each change now will reside in
 its own patch. for the local module makefiles, the only visible change
is PATCH_FILE_NAME -> PATCH_FILES. this variable now hold the list (and
apply prder) of the existing patches.

creating patches is almost the same as before (descibed in
http://external.openoffice.org/ext_dmake.html) with the difference that
each new patch requires two additional actions:
- rename the new patch to the desired name
- add the new patch at the end of PATCH_FILES

the description will be updated once this cws is integrated.

tschau...

ause

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

Re: [dev] Build fails: ERROR: can't deliver from local directory to SOLARVERSION

[Hans-Joachim Lankenau]

hi!

SOLARVERSION is the name of an environment variable and shouldn't appear 
as destination directory.

check your script for setting up the environment (winenv.set*)

tschau...

ause

codewench wrote:

I'm trying to build OpenOffice2 (DEV300_m10). I've been following the
instructions for 'Building OOo with Cygwin on Windows' (I'm using Visual
Studio 2008... although so far I don't see how any of these instructions
help me develop, build or debug using VS... but that's a whole other issue
right now)

In cygwin bash, when I type build --all -P2 this is what I see:

---
[EMAIL PROTECTED] /cygdrive/c/Projects/projGI/OOoSource_CVS/instsetoo_native
$ build --all P2
build -- version: 1.167

Fetching dependencies for module swext from solver... failed...
Fetching from CVS...  failed

=
Building module solenv
=
deliver -- version: 1.126
deliver: /cygdrive/c/Projects/projGI/OOoSource_CVS/solenv/prj/d.lst: ERROR
: can't deliver from local directory to SOLARVERSION

DANGER! Release Engineer:
do you really want to deliver from /cygdrive/c/Projects/projGI/OOoSource_C
VS/solenv to SOLARVERSION?
If so, please use the -force switch


ERROR: Error 1792 occurred while making solenv deliver

[EMAIL PROTECTED] /cygdrive/c/Projects/projGI/OOoSource_CVS/instsetoo_native
$ echo $SOLARVERSION
c:/Projects/projGI/OOoSource_CVS/solver/300
---

So far I've been able to figure out the multitude of errors and warnings
I've gotten, but I'm at a loss with this one. Any assistance is greatly
appreciated.

Thanks


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] detailed compiler version check and tg_compv.mk

[Hans-Joachim Lankenau]

hi!

Takashi Ono wrote:

Hi All,

In current OOo source tree, detailed compiler version check is being done in 
solenv/inc/tg_compv.mk and set to CCNUMVER. Compler version is also checked at 
configure time but the detailed version number does not seem to be passed to the 
build environment.


I am implementing mingw port and considering to support different experimental 
versions of mingw compilers. However, different versions of gcc compilers emit 
warnings in different manners and I have to change default compiler switches between 
versions. Unless, we have to face so many useless warnings or suppress many useful 
warnings. So I have to check the compiler version in solenv/inc/wntgcci6.mk but 
platform specific makefiles are included before solenv/inc/tg_compv.mk!

i see your problem...



I wonder why can't we pass the compiler version from the configure script and would 
like to have any suggestions.

there is no configure in SO environment...

what came into my mind was something like this:

in wntgcci.mk:

CFLAGSWARNCC=-Wsomething
CFLAGSWARNCC=-Wsomething_else

and and in settings.mk somewhere in the area of line 1170

.IF "$(CFLAGSWARNCC$(CCNUMVER))"!=""
CFLAGSWARNCC=$(CFLAGSWARNCC$(CCNUMVER))
.ENDIF

the idea behind: use the default and don't change the current settings 
if there is no specific setting available.


disclaimer: just an idea and completely untested :)

hope it helps...

[...]


tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] packing extensions in OOo environment

[Hans-Joachim Lankenau]

hi!

for those of you who are building extensions in the OOo/SO environment,
the following link could be of interest:

http://wiki.services.openoffice.org/wiki/Extensions_packing

beginning with DEV300_m18 the makefiles in

reportdesign/util
filter/source/pdfimport
sdext/source/minimizer

show the first real life usecases

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] cygwin version 1.5.25-5 seems to be broken for OOo build

[Hans-Joachim Lankenau]

hi!

other people also noticed problems:

http://sourceware.org/ml/cygwin/2007-12/msg00330.html

tschau...

ause

Hans-Joachim Lankenau wrote:
> hi!
> 
> after updating from 1.5.24-2 to 1.5.25-5 the created build dependencies
> (.dpslo/.dpobj) looked garbled and the build crashed (tested on m238 and
> m227 - just to be sure). restoring old cygwin1.dll manually made the
> build work again.
> 
> tschau...
> 
> ause
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] cygwin version 1.5.25-5 seems to be broken for OOo build

[Hans-Joachim Lankenau]

hi!

after updating from 1.5.24-2 to 1.5.25-5 the created build dependencies
(.dpslo/.dpobj) looked garbled and the build crashed (tested on m238 and
m227 - just to be sure). restoring old cygwin1.dll manually made the
build work again.

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] windows buildbot error message, bit of help ?

[Hans-Joachim Lankenau]

hi!

looks like version changes in assemblies happen outside of the source
code (no further comment...). so ccache takes the cached object as the
code didn't change...

should be fixed now (disabled ccache in these places).

tschau...

ause

Hans-Joachim Lankenau wrote:
> hi!
> 
> had a look at the problem:
> - reproducable with the existing local output tree
> - builds fine (-P4 -- -P4) with clean module
> 
> a testbuild died for other reasons:
> http://termite.go-oo.org/buildbot/Win-XP/builds/156/step-shell/1
> 
> :(
> 
> tschau...
> 
> ause
> 
> Caolan McNamara wrote:
>> So we've been getting this error for a while now on the windows
>> build-bot: http://buildbot.go-oo.org/buildbot/Win-XP
>>
>> "Error: .NET exception occured: System.IO.FileLoadException: Could not
>> load file or assembly ´cli_basetypes, Version=1.0.7.0, Culture=neutral,
>> PublicKeyToken=ce2cb7e279207b9e´ or one of its dependencies. The
>> located assembly´s manifest definition does not match the assembly
>> reference. (Exception from HRESULT: 0x80131040)"
>>
>> i.e. asking it to build just vanilla SRC680_m225
>> http://termite.go-oo.org/buildbot/Win-XP/builds/155/step-shell_5/1#err413
>>
>> It does seem to be able to build SRC680_m233, and there are some
>> changes to cli_ure between SRC680_m233 and SRC680_m235 (SRC680_m234
>> doesn't build for some other reason) of the "bump version" type.
>> Is this a problem specific to the buildbot alone or is it affecting all
>> SRC680_m235 builds on the same toolchain. It's incredibly frustrating,
>> without a windows buildbot we can't really contribute in a meaningful
>> way except for the the odd patch here and there.
>>
>> C.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] windows buildbot error message, bit of help ?

[Hans-Joachim Lankenau]

hi!

had a look at the problem:
- reproducable with the existing local output tree
- builds fine (-P4 -- -P4) with clean module

a testbuild died for other reasons:
http://termite.go-oo.org/buildbot/Win-XP/builds/156/step-shell/1

:(

tschau...

ause

Caolan McNamara wrote:
> So we've been getting this error for a while now on the windows
> build-bot: http://buildbot.go-oo.org/buildbot/Win-XP
> 
> "Error: .NET exception occured: System.IO.FileLoadException: Could not
> load file or assembly ´cli_basetypes, Version=1.0.7.0, Culture=neutral,
> PublicKeyToken=ce2cb7e279207b9e´ or one of its dependencies. The
> located assembly´s manifest definition does not match the assembly
> reference. (Exception from HRESULT: 0x80131040)"
> 
> i.e. asking it to build just vanilla SRC680_m225
> http://termite.go-oo.org/buildbot/Win-XP/builds/155/step-shell_5/1#err413
> 
> It does seem to be able to build SRC680_m233, and there are some
> changes to cli_ure between SRC680_m233 and SRC680_m235 (SRC680_m234
> doesn't build for some other reason) of the "bump version" type.
> Is this a problem specific to the buildbot alone or is it affecting all
> SRC680_m235 builds on the same toolchain. It's incredibly frustrating,
> without a windows buildbot we can't really contribute in a meaningful
> way except for the the odd patch here and there.
> 
> C.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Is someone still building OOo with tcsh?

[Hans-Joachim Lankenau]

hi!

Volker Quetschke wrote:
> CC'ing ESC and [EMAIL PROTECTED], please reply to [EMAIL PROTECTED] only.
> 
> Hi,
> 
> while working on some build feature/improvement for OOo W32 builds
> I realized that we have quite a lot of special casing of tcsh vs. bash.
really? beside setting up the environment, i'm can't think of any atm.

> 
> Is that still needed? I would like to remove the support for tcsh
> builds if possible. Opinions?
tcsh is still the default shell here for all builds not done on windows.
removing tcsh support would mean quite some impact here and doing so
without need doesn't sound reasonable to me.
> 
>   Volker
> 

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] To OOo Builders ...

[Hans-Joachim Lankenau]

hi!

Stephan Bergmann wrote:
> Kay Ramme - Sun Germany - Hamburg wrote:
>> - There are various files in solenv/inc, some of them having more or
>> less speaking names, while others are just differing by a prepanded
>> underscore (e.g. _tg_app.mk vs. tg_app.mk ). What is the meaning of
>> the underscore prefix? Is there an overview somewhere where I can find
>> some explanations regarding the makefile system?
> 
> _tg_app.mk is generated from tg_app.mk via some tool (whose name I
> forgot; mkunroll?), copying the input ninefold, replacing $(TNR) in the
> input with 1--9.
> 
> Arguably, only _tg_app.mk should be checked in, and tg_app.mk built
> afresh during each build.  This has already lead to errors in the past,
> where the two files went out of sync...
i would prefer generation the other way ;)

also the "unroll" tooling (mkunroll) currently orginates from module
tools which makes bootstrapping a bit harder...

any voluteers to rewrite in e.g. perl or C (please no java or python...)?

[...]

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Building m220

[Hans-Joachim Lankenau]

hi!

try with "dmake -V" if your dmake version is 4.7 or newer.

there was a change in the internal target representation of dmake 4.7
which required a change for the zip-target that broke compatibility with
older dmake versions.

your error looks like that...

tschau...

ause

A. Klitzing wrote:
> Hi there!
> 
> I have a problem with building m220 in my Ubuntu Feisty chroot.
> 
> I downloaded from the site [1]:
>   * core source
>   * system source
>   * sdk source
> and unpacked it.
> 
> I used ./configure in config_office with the flags from "cfg"-attachment
> and run LinuxX86Env.Set.sh, bootstrap and dmake.
> But after a while it will stop with errors (error.txt).
> 
> I tried some flags with tcsh instead of bash and "disable-fontooo",
> "without-fonts" and "without-afms" but everytime I get the same error.
> 
> Any ideas?
> 
> Regards,
> André Klitzing
> 
> 
> [1] http://download.openoffice.org/680/index.html
> 
> 
> 
> 
> 
> .
> 
> =
> Building project afms
> =
> /home/andre/SRC680_m220/afms
> mkout -- version: 1.7
> dmake: Executing shell macro: -test -d {$(subst,$/$(LANGDIR), 
> $(null,$(ZIP1DIR) . $(ZIP1DIR)))}/ && find {$(subst,$/$(LANGDIR), 
> $(null,$(ZIP1DIR) . $(ZIP1DIR)))}/ -type d ! -name CVS ! -name "." | sed 
> "s/\.\/\///" | sed "s/\.\///"
> --
> Making: ./unxlngi6/misc/afms.dpz
> dmake  -f makefile.mk  make_zip_deps=true ./unxlngi6/misc/fontunxafm.dpzz
> dmake: Executing shell macro: -test -d {$(subst,$/$(LANGDIR), 
> $(null,$(ZIP1DIR) . $(ZIP1DIR)))}/ && find {$(subst,$/$(LANGDIR), 
> $(null,$(ZIP1DIR) . $(ZIP1DIR)))}/ -type d ! -name CVS ! -name "." | sed 
> "s/\.\/\///" | sed "s/\.\///"
> echo # > ./unxlngi6/misc/fontunxafm.dpzz
> type 3
> mkdir -p ./unxlngi6/misc/build/Adobe-Core35_AFMs-314
> cd ./unxlngi6/misc/build/Adobe-Core35_AFMs-314 ; zipdep.pl -u -j -prefix 
> ./unxlngi6/misc/build/Adobe-Core35_AFMs-314/ ./unxlngi6/bin/fontunxafm.zip 
> "*.afm" "-x" "*Helvetica-Narrow*" -x "*CVS*" >> 
> /home/andre/SRC680_m220/afms/./unxlngi6/misc/fontunxafm.dpzz
> zipdep -- version: 1.12
> Multi Platform Enabled Edition
> cat ./unxlngi6/misc/fontunxafm.dpzz /tmp/mkPlBHY4 | grep -v "CVS" >> 
> ./unxlngi6/misc/afms.dpz
> echo zipdep_langs=en-US >> ./unxlngi6/misc/afms.dpz
> if ( -e ./unxlngi6/misc/build/Adobe-Core35_AFMs-314 ) mv 
> ./unxlngi6/misc/build/Adobe-Core35_AFMs-314 
> ./unxlngi6/misc/build/Adobe-Core35_AFMs-314_removeme 
> rm -rf ./unxlngi6/misc/build/Adobe-Core35_AFMs-314_removeme
> mkdir: cannot create directory `./unxlngi6/misc/': File exists
> mkdir: cannot create directory `./unxlngi6/misc/build': File exists
> dmake: Executing shell macro: $(TYPE) 
> $(PRJ)$/$(ROUT)$/misc$/$(TARFILE_NAME).unpack
> cd ./unxlngi6/misc/build && ( sh -c "gunzip -c 
> ../../../download/Adobe-Core35_AFMs-314.tar.gz  | tar  -xvf - ") && touch 
> so_unpacked_afms
> Adobe-Core35_AFMs-314/
> Adobe-Core35_AFMs-314/Courier-Bold.afm
> Adobe-Core35_AFMs-314/Courier-BoldOblique.afm
> Adobe-Core35_AFMs-314/Courier-Oblique.afm
> Adobe-Core35_AFMs-314/Courier.afm
> Adobe-Core35_AFMs-314/Helvetica-Bold.afm
> Adobe-Core35_AFMs-314/Helvetica-BoldOblique.afm
> Adobe-Core35_AFMs-314/Helvetica-Narrow.afm
> Adobe-Core35_AFMs-314/Helvetica-NarrowBold.afm
> Adobe-Core35_AFMs-314/Helvetica-NarrowBoldOblique.afm
> Adobe-Core35_AFMs-314/Helvetica-NarrowOblique.afm
> Adobe-Core35_AFMs-314/Helvetica-Oblique.afm
> Adobe-Core35_AFMs-314/Helvetica.afm
> Adobe-Core35_AFMs-314/ITCAvantGarde-Book.afm
> Adobe-Core35_AFMs-314/ITCAvantGarde-BookOblique.afm
> Adobe-Core35_AFMs-314/ITCAvantGarde-Demi.afm
> Adobe-Core35_AFMs-314/ITCAvantGarde-DemiOblique.afm
> Adobe-Core35_AFMs-314/ITCBookman-Demi.afm
> Adobe-Core35_AFMs-314/ITCBookman-DemiItalic.afm
> Adobe-Core35_AFMs-314/ITCBookman-Light.afm
> Adobe-Core35_AFMs-314/ITCBookman-LightItalic.afm
> Adobe-Core35_AFMs-314/ITCZapfChancery-MediumItalic.afm
> Adobe-Core35_AFMs-314/NewCenturySchlbk-Bold.afm
> Adobe-Core35_AFMs-314/NewCenturySchlbk-BoldItalic.afm
> Adobe-Core35_AFMs-314/NewCenturySchlbk-Italic.afm
> Adobe-Core35_AFMs-314/NewCenturySchlbk-Roman.afm
> Adobe-Core35_AFMs-314/Palatino-Bold.afm
> Adobe-Core35_AFMs-314/Palatino-BoldItalic.afm
> Adobe-Core35_AFMs-314/Palatino-Italic.afm
> Adobe-Core35_AFMs-314/Palatino-Roman.afm
> Adobe-Core35_AFMs-314/Symbol.afm
> Adobe-Core35_AFMs-314/Times-Bold.afm
> Adobe-Core35_AFMs-314/Times-BoldItalic.afm
> Adobe-Core35_AFMs-314/Times-Italic.afm
> Adobe-Core35_AFMs-314/Times-Roman.afm
> Adobe-Core35_AFMs-314/ZapfDingbats.afm
> Adobe-Core35_AFMs-314/MustRead.html
> make writeable...
> --
> Making: ./unxlngi6/bin/fontunxafm.zip
> rebuilding zipfiles
> -- 
> cp: cannot stat `./unxlngi6/bin/fontunxafm.zip': No such file or directory
> cd ./unxlngi6/misc/build/Adobe-Core35_AFMs-314 ; zip -u -j 
> /tmp/mksGVd6m.fontunxafm./_.zip *.afm -x "*Helvetica-Narrow*" -x delzip  -x

[dev] generated component_getDescriptionFunc removed

[Hans-Joachim Lankenau]

hi!

in SRC680_m218 adding a fallback function to each shared library, just
stating that there is no description, was removed.

also generating component_getDescriptionFunc from a description.xml file
was removed too as it was unused for years.

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Re:Re:building prolbem in "instsetoo_native" of OOE680_m6 with Cygwin

[Hans-Joachim Lankenau]

hi!

your change in rules.mk won't help as perl still needs cygwin notation
to process the parameters. try the attached patch which inserts guw.exe
when calling the native binary.

tschau...

ause

Canghua Qu wrote:
> Hi, Ruediger
> 
> Thank you very much ! :)
>>> I have a problem in building "instsetoo_native" (OOE680_m6) with cygwin  on 
>>> Windows XP.
>>> There is no error until building "basctl", and then errors come out 
>>> frequently, so I have to manually modify the files generated in 
>>> "\..\wntmsci11.pro\" ,then kept on building the following modules one by 
>>> one. 
> 
>> I think that's the wrong approach. You have to really fix the problem here 
>> in basctl (and above).
> I tried to dmake another source environment, and the error comes out in 
> "basctl" again. But I can't fix it this time. The error in basctl is:
> **
> Sorry, the error is :
>  basidesh_3120.c1
> .\baside2.hrc(38) : fatal error C1083: Cannot open include file: 
> 'basidesh.hrc':No such file or directory
> ERROR - calling compiler for preprocessing failed
> dmake: Error code 2, while making '../../wntmsci11.pro/srs/basidesh.hid'
>  ---* tg_merge.mk *---
> ERROR: Error 65280 occurred while making 
> /cygdrive/e/ooo_OOE680_m6_src/basctl/so urce/basicide
> ***
> 
>> Sorry, but we cannot help you as long as we do not know what you did
>> before. Obviously your build has problems long before which you somehow
>> worked around (see above). Your workaround seems not to be sufficient.
> 
> What I have done are:
> 1. change the line about # generate hid files in rules.mk (\solenv\inc\) 
> from:
>+$(PERL) $(SOLARENV)$/bin$/mhids.pl $*.src $(SRS) $(PRJNAME) 
> $(CDEFS) $(INCLUDE)
> To: 
> +$(WRAPCMD) $(PERL) $(SOLARENV)$/bin$/mhids.pl $*.src $(SRS) 
> $(PRJNAME) $(CDEFS) $(INCLUDE)
> 
> 2. do configure
> 3. in ooo_OOE680_m6\winenv.set.sh:
>1) remove the line :  NO_HIDS="TRUE"
> 2) remove NO_HIDS in the "export" field
> 3) add a line "export PROF_EDITION=TRUE"
> 4. do dmake
> 
> Then error comes out in module "basctl" as above.
> 
> I don't know how to resolve it now. I need your help! 
> Thank you very  much!
> 
> Best Regards,
> Canghua
> 

Index: mhids.pl
===
RCS file: /cvs/tools/solenv/bin/mhids.pl,v
retrieving revision 1.8
diff -u -r1.8 mhids.pl
--- mhids.pl	12 Oct 2006 13:49:53 -	1.8
+++ mhids.pl	4 Jun 2007 11:52:53 -
@@ -182,7 +182,7 @@
 #call  perl5 -p -e "s/=[ \t]*\".*\"/=\"\"/go; s/\".*\"[ \t]*;/\"\" ;/go ; s/(\".*)\/\/(.*\")/$1\/\\\/$2/go ;" < %filename% > %srs%\%workfile%.c0
 
 print  "hidc $filename ${shell_workfile}.c1 $prjname \n";
-$ret = system "hidc $filename ${shell_workfile}.c1 $prjname";
+$ret = system "$ENV{WRAPCMD} hidc $filename ${shell_workfile}.c1 $prjname";
 if ( $ret ) {
 	push @cleanuplist, ".c1";
 	cleandie("ERROR - calling \"hidc\" failed");

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Error on dmake: Could not detect compiler version

[Hans-Joachim Lankenau]

hi!

OOo 2.0.4 doesn't yet know about this compiler. IIRC, initial support
was introduced in SRC680 m(ilestone)186.

tschau...

ause

Pathani, Radhika (GE, Corporate, consultant) wrote:
> Hi,
>  I am getting the following error message dhile doing 'dmake'.i'm using
> MS Visual 2005 Express Edition .i've configured as per the document. but
> still the problem coming.
> ---
> ERROR! 
> Could not detect compiler version! 
> Please extend tg_compv.mk in 
> solenv/inc. 
>  
> guw.pl /cygdrive/c/PROGRA~1/MID05A~1/VC/bin/cl.exe returns 
> dmake: Error code 53, while making 'compiler_version_error' 
> ---* tg_merge.mk *--- 
> 
> ERROR: Error 65280 occurred while making
> /cygdrive/d/compile/openoffice/installa 
> tion_pkg/oo_2.0.4_src/boost 
> dmake: Error code 1, while making 'build_instsetoo_native' 
> 
> .. 
> 
> 
> please help me to resolve the same.
> 
> Thanks and Regards
> Radhika
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] how does OOo wiki search work?

[Hans-Joachim Lankenau]

hi!

Bernhard Dippold wrote:
> Hi Ause,
> 
> Hans-Joachim Lankenau schrieb:
>> hi!
>>
>> maybe someone here can enlighten me on some surprising results of the
>> OOo wiki search function:
>>
>> given the page
>>
>> http://wiki.services.openoffice.org/wiki/Precompiled_header_%28PCH%29
>>
>> i would expect to get at least some page text matches when searching for
>> "pch" but no avail. using upper case doesn't help either...
> 
> IIRC there is a minimum of 4 letters for the search in the wiki.
> 
> But I might be wrong...
hmm, looks like your right. neither CWS nor MWS gives any search results...

might be usefull to allow three letter searches too...

[...]

thanks!

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] + prefix in makefiles

[Hans-Joachim Lankenau]

hi!

with SRC680 m201 lots of makefiles have been cleaned up to no longer use
forced shell calls (the "+" found in a lot of targets). these shell
calls are causing build slowdown (especially on windows in incremental
builds).

for details have a look at

http://wiki.services.openoffice.org/mwiki/index.php?title=Forced_shell_calls&oldid=23881

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] how does OOo wiki search work?

[Hans-Joachim Lankenau]

hi!

maybe someone here can enlighten me on some surprising results of the
OOo wiki search function:

given the page

http://wiki.services.openoffice.org/wiki/Precompiled_header_%28PCH%29

i would expect to get at least some page text matches when searching for
"pch" but no avail. using upper case doesn't help either...

looking for "precompiled" indicates that this page isn't ignored completely.

is there anything wrong with this page or is OOo wiki search simply broken?

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] PCH where we are

[Hans-Joachim Lankenau]

hi!

ok, i'm late,. but better late than never...

Kai Backman wrote:
> On 1/4/07, Hans-Joachim Lankenau <[EMAIL PROTECTED]> wrote:
>> with cws pchfi04 it was planned to use non-dummy precompiled header in a
>> number of modules that should benefit most. the precompiled_.hxx
>> were created with the simplistic approach to include all used header
>> found in the module and strip those that hinder compilation.
>>
>> unfortunately, when taking a closer look, this isn't sufficient.
> 
> First, before we go forward. I'm pretty sure pchfix04 still contains
> issues and I agree that we need to look into them. That is the exact
> reason why the feature is marked as EXPERIMENTAL in ./configure and
> not enabled by default.
> 
>  However, finding these problems is significantly faster if it is
> easy for everyone to -test- them, which means the CWS should be
> integrated sooner with issues rather than later when it's totally
> perfect. It is not turned on by default. You can build using both
> ways. You RE guys hate gigantic CWS's, maybe we should save some fixes
> for pchfix05 and later?
as the windows nonpro build here uses pch by default to make sure to
detect missing includes, it's at least mandatory not to break the build
and have some somehow usable results.

> 
> 
>> e.g. in sd/source/core/drawdoc.cxx you find these lines:
>>
>> ...
>> #define ITEMID_SCRIPTSPACE  EE_PARA_ASIANCJKSPACING
>> #include 
>> ...
>>
>> this include uses the define to pass the default parameter to
>>
>> SvxScriptSpaceItem( sal_Bool bOn = sal_False,
>> const sal_uInt16 nId = ITEMID_SCRIPTSPACE );
> 
>  In this particular case the need for ITEMID_SCRIPTSPACE can be
> entirely avoided by removing the default values and instead passing in
> the parameters explicitly. A quick look at the all the OOo code found
> me 7 invocations of the SvxScriptSpaceItem constructor so it should be
> pretty trivial.
> 
> ...
> 
> The bigger question is why are such constructs used in the first
> place? Modifying a hxx file using a define is just plain bad
> programming in most cases. In this case it's not even excused by a
> desire to simulate templates.  If a module wants to define a default
> script space, why not just do:
> 
> const sal_uInt16 kSD_DefaultScriptSpace = EE_PARA_ASIANCJKSPACING;
> 
> ...
> new SvxScriptSpaceItem(sal_False, kSD_DefaultScriptSpace);
> 
>  In sd this is even simpler as there is only a single use of the
> constructor so we can just update that single invocation.
agreed, it's a matter of our codebase. see #i73604#

> 
> 
>> another point that worries me is the different list of includes
>> depending on using pch or not.
> 
>  Yes! Headers that are order dependent are usually broken in more
> than one ways anyway. Finding them by turning on pch would be a Good
> Thing.
though i'm not a c/c++ expert, i also agree on this one.

> 
> 
>> at the moment, i'm not sure that this "all you can include" approach
>> will come to an happy end. maybe cautiously selecting a set of includes
>> for the precompile hxx would be more appropriate regarding the two
>> issues i currently see...
> 
>  At this point we have 8645 #include statements in the the various
> pch files. It took martink and me about a month to come up with this
> list using our simple strategy. Who will do this cautious selection?
> Would it perhaps be a better idea to include those fixes in pchfix05?
due to the concept of using pch, these code issues are more likely to
pop up with pch although they are not limited to pch and may happen in
non pch build too.
since there seems to be some agreement that these constructs are worth
fixing, it raises the hope that it will be possible to go on with
including a large set of files into pch without damaging the build by
design.

> 
> 
> On 1/5/07, Stephan Bergmann <[EMAIL PROTECTED]> wrote:
>> > a very simple result is that developers using pch will break the build
>> > of those not using pch without being able to notice if new includes are
>> > required that already reside in the precompiled file. any c/c++ expert
>> > may be able to construct more elaborate error cases caused by this...
>>
>> What is worse, there can be cases where both versions build fine but
>> behave differently (e.g., h1.hxx declares f(Base*), h2.hxx declares
>> f(Derived*), u.cxx calls f with a Derived* and without pch only sees
>> h1.hxx but with pch sees both h1.hxx and h2.hxx).
> 
>  Ok. Setting aside the fact that this will happen without pch
> (someone could still include h2.hxx), I don'

[dev] PCH where we are

[Hans-Joachim Lankenau]

hi!

with cws pchfi04 it was planned to use non-dummy precompiled header in a
number of modules that should benefit most. the precompiled_.hxx
were created with the simplistic approach to include all used header
found in the module and strip those that hinder compilation.

unfortunately, when taking a closer look, this isn't sufficient.

e.g. in sd/source/core/drawdoc.cxx you find these lines:

...
#define ITEMID_SCRIPTSPACE  EE_PARA_ASIANCJKSPACING
#include 
...

this include uses the define to pass the default parameter to

SvxScriptSpaceItem( sal_Bool bOn = sal_False,
const sal_uInt16 nId = ITEMID_SCRIPTSPACE );

so, why doesn't this fail in the precompile_sd.hxx? for whatever reason,
this define is set in svx/inc/eeitemid.hxx (in this case to the same
value by chance) and due to the internal include guards,
scriptspaceitem.hxx isn't revisited with the define set in the cxx file.
in svx there are about 70 hxx files like this and there is also one
known in sfx2 (srchitem.hxx).

this example shows there are still errors lurking that cannot be
detected while building. and even when removing "context sensitive"
includes in precompiled_.hxx, the next codechange may bring them
 back indirect.


another point that worries me is the different list of includes
depending on using pch or not.

a very simple result is that developers using pch will break the build
of those not using pch without being able to notice if new includes are
required that already reside in the precompiled file. any c/c++ expert
may be able to construct more elaborate error cases caused by this...

simply removing the guards in the current precompile_.hxx to
align the includes again seems to be no option as it slows down
compiltation without pch by round about a factor of four compared to the
compile times today (may be even more on windows...).


at the moment, i'm not sure that this "all you can include" approach
will come to an happy end. maybe cautiously selecting a set of includes
for the precompile hxx would be more appropriate regarding the two
issues i currently see...

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Another error while building ooo_src680_m193

[Hans-Joachim Lankenau]

hi!

#i64134#?

tschau...

ause

Pema Geyleg wrote:
> Hi all,
> 
> Thanks to Christian and Hans for pointing me to the
> http://mail1.druknet.bt/Redirect/www.openoffice.org/issues/show_bug.cgi?id=71438
> 
> for my earlier error.
> 
> Now I m getting the following error.
> 
> 
> /srv/projects/openoffice/ooo_SRC680_m193_src/solver/680/unxlngi6.pro/lib/libaudi
> o.a(ConnSvr.o): In function `GetAuthorization':
> /srv/projects/openoffice/ooo_SRC680_m193_src/nas/unxlngi6.pro/misc/build/nas-1.6
> /lib/audio/ConnSvr.c:1981: undefined reference to `XauDisposeAuth'
> /srv/projects/openoffice/ooo_SRC680_m193_src/nas/unxlngi6.pro/misc/build/nas-1.6
> /lib/audio/ConnSvr.c:1832: undefined reference to `XauGetBestAuthByAddr'
> collect2: ld returned 1 exit status
> dmake:  Error code 1, while making
> '../unxlngi6.pro/lib/libvclplug_gen680li.so'
> '---* tg_merge.mk *---'
> 
> ERROR: Error 65280 occurred while making
> /srv/projects/openoffice/ooo_SRC680_m19 3_src/vcl/util
> dmake:  Error code 1, while making 'build_instsetoo_native'
> '---*  *---'
> 
> I tried searching for the same error in issuzilla but had been
> unsuccessful.
> Thanks in advance for the help.
> Many Thanks
> Pema Geyleg
> DIT,MoIC.
> Thimphu,Bhutan.
> +++
> Get a free DrukNet e-mail account and stay in touch
> http://www.druknet.bt   
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] precompiled header support and how not to break it

[Hans-Joachim Lankenau]

hi!

with the integration of cws ause060, "--enable-pch" will tell configure
to enable precompiled header support for most modules, currently on
windows only.

this is based on the include lines in every c/c++ file introduced by the
pchfix* cws:



// MARKER(update_precomp.py): autogen include statement, do not remove
#include "precompiled_.hxx"



unfortunatly, with enabled pch the windows build will break in those
modules on the first source file _NOT_ containing this include statement.

so if you're adding new sources, please make sure to fetch those lines
from one of your neighbour sources and place them in your new file as
_FIRST_ include made.

tschau...

ause

ps: wiki page will follow

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] "make" a python script in makefile.mk?

[Hans-Joachim Lankenau]

hi!

UNIXTEXT was introduced to make sure the resulting file gets cleaned
from dos lineends.
there is currently nothing similar available for windows :(

Leibowitz, Michael wrote:
> I'm having some trouble with "making" scripts in my makefile.mk.  In
> UNIX, I use "UNIXTEXT = $(MISC)/dbbe_enable.sh"  That seems to work.
> However, on Windows, I don't know of any similar variable.  I tried
> putting in my own target:
> 
> # --- Targets --
> 
> .INCLUDE : target.mk

# insert your target in the dependency chain
ALLTAR : $(MISC)$/dbbe_enable.py
> 
> $(MISC)$/dbbe_enable.py: dbbe_enable.py
> +cp $? $@
> 
> But, this doesn't seem to have any effect.  Any hints??
> 

better use $(COPY) or $(GNUCOPY) instead of "cp"

tschau...

ause

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] parallel builds

[Hans-Joachim Lankenau]

hi!

"build -Pn" problems are worth an issue too. if you cannot locate the
owner, pass it over to me ([EMAIL PROTECTED]).

tschau...

ause

Christian Lohmaier wrote:
> Hi Volker,
> 
> On Sat, Jul 01, 2006 at 03:35:06PM -0400, Volker Quetschke wrote:
>> Christian Lohmaier wrote:
>>> On Fri, Jun 30, 2006 at 09:19:04PM -0700, Leibowitz, Michael wrote:
>>>
 Is there a way to make parallel builds (make -jn equivalent) with the
 vanilla build system?  I know that ooo-build offers --with-num-cpus=n
>>>
>>> There is, but it is likely that the build will break/has to be rerun
>>> because of missing build problems.
>  that have been "dependencies"
> 
>> Hmm, please file issues if you find such problems. `build -- -P2` builds
>> work for W32-tcsh.
> 
> dmake-level parallel builds work here as well. 
> 
> ciao
> Christian

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] build.pl and dmake

[Hans-Joachim Lankenau]

hi!

just two short checks for your dmake:
- it should be located at .../solenv/wntmsci10/bin and "which dmake"
should be giving you this one
- try "dmake -V" and see if MAKESTARTUP got a "/" as delimiter, matching
the tcsh.

tschau...

ause

Alexandre Laforest wrote:
> Greetings
>  
> I've been trying to build OOo 680 with 
>  
> - Windows 2000 Pro SP4
> - MS Visual Studio .NET 2003
> - gcc 3.3.1
> - j2sdk1.4.2_11
> - Cygwin 1.5.19
> - VMWare 5.5
>  
> I managed to get through the configure and bootstrap script following the 
> instructions found at 
> http://tools.openoffice.org/dev_docs/build_windows_tcsh.html and the help of 
> people in this newsgroup. But now, I'm stuck trying to use 'dmake'. Using 
> tcsh and sourcing 'winenv.set' works fine (well, it does not raise any 
> errors/exceptions), but then I type 'dmake' (as said in the build procedure 
> :P) and get this error:
>  
> Checking module list
> Can't open perl script 
> "/cygdrive/e/src_root/OOb680_m5/solenv/bin/build.pl": No
> such file or directory
> dmake:  Error code 2, while making 'check_modules'
> ---*  *---
>  
> I tried a couple of things with Chris H's help: most relevant was trying to 
> run 'build.pl' from its location (OOb680_m5/solenv/bin/). It kinda worked, 
> returning 
> 
> build -- version: 1.145
>  
> =
> Building project solenv
> =
>  
> Does not seem to be any errors but does not seem to be anything built 
> either... So I am puzzled. 
>  
> Any pointers, ideas, suggestions, questions would be greatly appreciated.
>  
> Thanks a bunch
>  
> Alexandre L.
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Compilation error with gcc 3.3.5

[Hans-Joachim Lankenau]

hi!

did you use the prebuilded mozilla libraries?

tschau...

ause

Takashi Nakamoto wrote:
> Hi,
> 
> I've tried to compile SRC680_m125 with gcc 3.3.5 (SUSE Linux professional
> 9.3) and I got following error message. I found some issues that may relate
> in any way to this problem but no solution.
> 
> While compiling with gcc 3.3.x, build process must not use libstdc++.so.6
> but libstdc++.so.5. However, I don't know which file specify "libstdc++"
> version number. Anybody tell me which file cause this problem or how to
> resolve this problem.
> 
> =
> mv ../../../unxlngi4.pro/lib/libmozabdrv2.so
> ../../../unxlngi4.pro/lib/check_libmozabdrv2.so
> /home/ooosrc/m125/solenv/bin/checkdll.sh -L../../../unxlngi4.pro/lib
> -L../lib -L/home/ooosrc/m125/solenv/unxlngi4/lib
> -L/home/ooosrc/m125/solver/680/unxlngi4.pro/lib
> -L/home/ooosrc/m125/solenv/unxlngi4/lib -L/usr/lib/jvm/java-1.4.2-sun/lib
> -L/usr/lib/jvm/java-1.4.2-sun/jre/lib/i386
> -L/usr/lib/jvm/java-1.4.2-sun/jre/lib/i386/client
> -L/usr/lib/jvm/java-1.4.2-sun/jre/lib/i386/native_threads -L/usr/X11R6/lib
> ../../../unxlngi4.pro/lib/check_libmozabdrv2.so Checking DLL
> ../../../unxlngi4.pro/lib/check_libmozabdrv2.so ...: ERROR: libstdc++.so.6:
> cannot open shared object file: No such file or directory dmake:  Error code
> 1, while making '../../../unxlngi4.pro/lib/libmozabdrv2.so' '---*
> tg_merge.mk *---'
> 
> ERROR: Error 65280 occurred while making
> /home/ooosrc/m125/connectivity/source/drivers/mozab dmake:  Error code 1,
> while making 'build_instsetoo_native' '---* tg_merge.mk *---'
> =
> 
> Regards,

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] SimpleBootstrap_cpp Makefile Issue

[Hans-Joachim Lankenau]

hi!

just a wild guess without actually knowing your makefile:

maybe concatination of the two variables leaves a string containing a 
blank. that would break matching the rule.


to check, try

ttt:
echo $(OUT_APP_OBJ)

as the first target in your makefile but after setting this variable.

tschau...

ause

Pierre-Andre Galmes wrote:

Hello,

After some more investigation, I found the following. The problem comes
from the following call :

$(OUT_BIN)/_%$(EXE_EXT) : $(OUT_APP_OBJ)/%.$(OBJ_EXT)

The problem is the value of the $(OUT_APP_OBJ) variable. After some test
this is what I found. Depending on the value it may or may not compile.
The original value does not compile :

# Not ok
OUT_APP_OBJ = $(OUT_OBJ)/$(APP_NAME)
OUT_APP_OBJ = $(OUT_OBJ)$(APP_NAME)

But the following do :

# OK
OUT_APP_OBJ = $(APP_NAME)
OUT_APP_OBJ = $(OUT_OBJ)
OUT_APP_OBJ = $(OUT_BIN)
OUT_APP_OBJ = /$(OUT_OBJ)/

With

OUT_OBJ = /opt/OpenOffice.org2.0_SDK/examples/DevelopersGuide/ProfUNO/
CppBinding/build/OpenOffice.org2.0_SDK/LINUXexample.out/obj
APP_NAME =  SimpleBootstrap_cpp


Any Idea of wht may be wrong ? Might be an idea to the make a patch to
correct this problem.

Cheers,
Pierre-Andre


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Build project POSTPROCESS fail !

[Hans-Joachim Lankenau]

hi!

i would rather call it "rarely used"...

but you're right that a 4nt build isn't a good choice if you just want 
to have a trouble free build...


tschau...

ause

Volker Quetschke wrote:

I having a problem when building project POSTPROCESS.
I read similar issues: issue 36845, issue 38176, issue 41780, issue 
50129.

But I DID NOT solve the problem.

Please read my detail problem at Issue 50512 and help me to solve this.


I just wrote the same answer in that issue,

please follow the build instructions carefully:
  

The build using 4nt is currently *NOT* supported! Please bin you source
tree to avoid interactions with a previous W32-4nt build and start over
with W32-tcsh.

Volker


--
If you like my work consider:  http://www.scytek.de/donations.html
PGP/GPG key  (ID: 0x9F8A785D)  available  from  wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913  9E53 3D35 C9BA 9F8A 785D


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]