Apache OpenOffice (AOO) Bugzilla – Issue 8147
Cannot compile on Windows
Last modified: 2004-02-17 09:03:49 UTC
I see the following error after "configure". Even I try to make other modules, it still didn't work out, the error message is similar to those below. -- [e:\oo_643_src]dmake build -- version: 1.61 ============= Building project freetype ============= E:/oo_643_src/freetype "#" "#" "#" ERROR: minor.mk in solenv\inc does not match your version! "#" "#" dmake: e:\oo_643_src\solenv/inc\settings.mk: line 127: Error -- force_dmake_t o_error: No such file or directory ---*SETTINGS.MK*--- ERROR: Error 65280 occurred while making E:/oo_643_src/freetype dmake: Error code 129, while making 'build_all' ---*TG_SLO.MK*---
check the minor.mk file in solenv/inc. It may say SRX643, whereas your WORK_STAMP variable is set to SRC643. I thought we had fixed that for the SRX643_OO branch in set_soenv.in so that the WORK_STAMP becomes SRX... Edit your winenv.bat file to change SRC643 to SRX643 (assuming SRX is in minor.mk), re-execute winenv.bat and try again.
Thanks, but there's another error: -- [e:\oo_643_src]dmake build -- version: 1.61 ============= Building project freetype ============= E:/oo_643_src/freetype dmake: Error code 129, while making 'e:\oo_643_src\solver\643 \wntmsci7.pro\inc\ 643minor.mk' ---*SETTINGS.MK*--- ERROR: Error 65280 occurred while making E:/oo_643_src/freetype dmake: Error code 129, while making 'build_all' ---*TG_SLO.MK*---
Cannot reproduce and don't understand... the following part of solenv/inc/settings.mk should take care of the creation of 643minor.mk: .IF "$(GUI)"=="UNX" @+tr -d "\015" < $(SOLARENV)$/inc$/minor.mk > $(SOLARVERSION)$/$(INPATH)$/inc$(UPDMINOREXT)$/$(UPD)minor.mk @+$(TOUCH) $(SOLARVERSION)$/$(INPATH)$/inc$(UPDMINOREXT)$/minormkchanged.flg >& $(NULLDEV) .ELSE # "$(GUI)"=="UNX" @+$(COPY) $(SOLARENV)$/inc$/minor.mk $(SOLARVERSION)$/$(INPATH)$/inc$(UPDMINOREXT)$/$(UPD)minor.mk >& $(NULLDEV) @+$(TOUCH) $(SOLARVERSION)$/$(INPATH)$/inc$(UPDMINOREXT)$/minormkchanged.flg >& $(NULLDEV) .ENDIF # "$(GUI)"=="UNX" try a 'build -p' (better pipe output into a file) and see whether it does this or misses some environment variable settings...
update config_office again. run configure again. The tag for SRX643_OO move backwards in the tree somehow. I have moved the tag to the latest version with a number of fixes in place including Armins.
I've done a fresh checkout using the tag SRX643_OO, here's what I got after "configure": ============= Building project freetype ============= E:/SRX643_OO/SRX643_OO/freetype ++++++++++++++++++++++++++++++++++++ ERROR! Could not detect compiler version! Please extend tg_compv.mk in "solenv/inc". ++++++++++++++++++++++++++++++++++++ "guw.pl cl " returns 4NT: Unknown command "guw.pl" dmake: Error code 130, while making 'compiler_version_error' ---*TG_SLO.MK*--- ERROR: Error 65280 occurred while making E:/SRX643_OO/SRX643_OO/freetype dmake: Error code 129, while making 'build_all' ---*TG_SLO.MK*---
A "build -p" gives the following: -- [e:\srx643_oo\srx643_oo]build -p build -- version: 1.61 -- it does not proceed after over an hour.
guw.pl is in solenv/bin which 'winenv.bat' should put into your PATH. If not, then something seems to have gone wrong there.
I've pulled down the latest source in SRX643_OO and here's what I got after "configure": Seems like using latest Cygwin is better than using the B20. -- [e:\srx643_oo]dmake build -- version: 1.61 ============= Building project freetype ============= E:/SRX643_OO/freetype mkout -- version: 1.3 4NT: Unknown command "awk" 4NT: Unknown command "awk" ++++++++++++++++++++++++++++++++++++ ERROR! Could not detect compiler version! Please extend tg_compv.mk in "solenv/inc". ++++++++++++++++++++++++++++++++++++ "cl " returns Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] ++++++++++++++++++++++++++++++++++++ dmake: Error code 255, while making 'compiler_version_error' ---*TG_SLO.MK*--- ERROR: Error 65280 occurred while making E:/SRX643_OO/freetype dmake: Error code 129, while making 'build_all' ---*TG_SLO.MK*--- [e:\srx643_oo]awk
I guess there's something wrong with my cygwin, I shall check it and report back. Sorry if I'm creating trouble due to my own mistake.
yes, use a new cygwin shell. We got rid of the need of the ancient b20 version. Things go much easier with the new one, see the build docs. There was only one thing to fix manually left: the symlinks of (g)awk caused some problems, and you should copy the linked file over rather than using the symlink.
Seems like the winenv.bat has some problem, the first one is generated by the configure script: set DELIVER="perl e:\643\solenv\bin\deliver.pl" and the second one is obtained from the 642 build: set DELIVER=%COMSPEC -c call perl %SOLARENV\bin\deliver.pl Both does not work, however: -- [e:\643]dmake build -- version: 1.61 ============= Building project freetype ============= /cygdrive/e/643/freetype ------------- Can't open perl script "e:643solenvbindeliver.pl": No such file or directory
Despite that error, the "final" error which kicks me out back to the prompt is: thanks. -- ============= Building project soltools ============= /cygdrive/e/643/soltools/mkdepend ------------------------------ Making:..\wntmsci7.pro\bin\makedepend.exe link /COMMENT:"soltools_643______" /MACHINE:IX86 @C:\DOCUME~1 \ADMINI~1\LOCALS~1 \Temp\mkc1 Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. c:\PROGRA~1\MICROS~2\VC98\bin\cl.exe /MAP /NODEFAULTLIB /OPT:NOREF /RELEASE /SUBSYSTEM:CONSOLE /BASE:0x1b00 0000 /BASE :0x1100000 -out:..\wntmsci7.pro\bin\makedepend.exe - map:..\wntmsci7.pro\misc\mak edepend.map ..\wntmsci7.pro\obj\cppsetup.obj ..\wntmsci7.pro\obj\ifpar ser.obj .. \wntmsci7.pro\obj\include.obj ..\wntmsci7.pro\obj\main.obj ..\wntmsci7 .pro\obj\p arse.obj ..\wntmsci7.pro\obj\pr.obj msvcrt.lib kernel32.lib user32.lib oldnames. lib c:\PROGRA~1\MICROS~2\VC98\bin\cl.exe : fatal error LNK1136: invalid or corrupt f ile dmake.exe: Error code 240, while making '..\wntmsci7.pro\bin\makedepend.exe' ---*TG_SLO.MK*--- ERROR: Error 65280 occurred while making /cygdrive/e/643/soltools/mkdepend dmake: Error code 129, while making 'build_all'
Please update the config_office directory again. Volker foudn a problem with the windows build script that was resolved yesterday. To recoever from this: cd config_office ./configure cd .. dmake clean ### purge everything ./bootstrap Then continue with the build as before.
*** Issue 8539 has been marked as a duplicate of this issue. ***
Thanks, I've updated my source and it seems going better, at least some projects/modules got compiled apparently, here's the first error I got in zlib: -- ============= Building project zlib ============= E:/643/zlib ------------- echo dummy > .\wntmsci7.pro\misc\build\zlib-1.1.4\makefile.mk 4NT: The system cannot find the path specified. "E:\643\zlib\wntmsci7.pro\misc\build\zlib-1.1.4\makefile.mk" C:\cygwin\bin\touch.exe .\wntmsci7.pro\misc\build\zlib-1.1.4 \makefile.mk /usr/bin/touch: creating `.\\wntmsci7.pro\\misc\\build\\zlib-1.1.4 \\makefile.mk' : No such file or directory cd .\wntmsci7.pro\misc\build && ( type ..\..\..\zlib-1.1.4.patch | tr -d "\015" | patch -b -p2 ) && C:\cygwin\bin\touch.exe so_patched can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |*** misc/zlib-1.1.4/makefile.mk Tue Aug 20 18:41:36 2002 |--- misc/build/zlib-1.1.4/makefile.mk Tue Aug 20 18:41:21 2002 -------------------------- File to patch: ---*TG_SLO.MK*--- ---*TG_SLO.MK*---
I found similar problem with some other modules as well... all about patch.
I've d/l'ed the solver and things go on much better except the module setup2: -- [e:\643n\setup2]build build -- version: 1.61 E:/643n/setup2/script ------------- E:/643n/setup2/jsnative ------------- E:/643n/setup2/unotypes ------------- E:/643n/setup2/win/source/pguard ------------- E:/643n/setup2/source/agenda ------------- E:/643n/setup2/win/source/loader ------------------------------ Making:..\..\..\wntmsci7.pro\res\07\loader.res rc -I. -I. -I..\inc -I..\..\..\inc -I..\..\..\WIN\inc - I..\..\..\wntmsci7.pro\in c -I. -Ie:\643n\solver\643\wntmsci7.pro\inc\stl -Ie:\643n\solver\643 \wntmsci7.pr o\inc\external -Ie:\643n\solver\643\wntmsci7.pro\inc - Ie:\643n\solenv\wntmsci7\i nc -Ie:\643n\solenv\inc -Ie:\643n\res -Ie:\643n\solver\643 \wntmsci7.pro\inc\stl -Ic:\jdk1.3.1_03\include\win32 -Ic:\jdk1.3.1_03\include -Ic:\progra~1 \micros~2\v c98\include -Ic:\PROGRA~1\MICROS~3\include -I. -I..\..\..\res - I. -Ie:\643n\ solver\643\wntmsci7.pro\res -d RUSS -r -DWIN32 - fo..\..\..\wntmsci7.pro\res\07\l oader.res loader.rc loader.rc (311): error RC2104 : undefined keyword or key name: 迶蠉膼碭 籦?瀔鍏譇 擤?鴈儗魰錒賥賾殣?.. dmake: Error code 129, while making '..\..\..\wntmsci7.pro\res\07 \loader.res'
And the consquence is that, on installation, the following files are missing: 1. tk643xx.res 2. set643xx.res 3. reg4msdoc643xx.res I've pulled in the setup2 module from CVS but the problem persists.
Alright, I could finally compile one localized (88) installation set myself. The problem was on some incomplete localization I suppose (07) since there's error there. However, on installation, everything seems fine until I press the first "Next" button. It looks as that Windows is not refreshed except the blue title bar, and follow by a few more "Next", the installation will not proceed and it halts with and error like: -- setup.exe - Application Error The instruction at "0x1c6e478a" referenced memory at "0x01010111". The memory could not be "read". Click on OK to terminate program Click on CANCEL the debug the program -- The "Context" shows "VCL643MI! (0x1c6e478a)". Any suggestion? Thanks.
don't know what goes wrong - I pull in the owner of 'installation'
I can't help in this case. I've nothing to do with the build. Martin, any ideas?
that looks like i18n is not functioning !
is that problem still present/valid ?
The following error occurs again with the latest ooo_643c_src tarball: == ============= Building project freetype ============= /cygdrive/e/OO643C/oo_643c_src/freetype ++++++++++++++++++++++++++++++++++++ ERROR! Could not detect compiler version! Please extend tg_compv.mk in "solenv/inc". ++++++++++++++++++++++++++++++++++++ "c:\PROGRA~1\MICROS~2\VC98\bin\cl.exe " returns Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved. usage: cl [ option... ] filename... [ /link linkoption... ] ++++++++++++++++++++++++++++++++++++ dmake.exe: Error code 255, while making 'compiler_version_error' ---*TG_SLO.MK*--- ERROR: dmake - not a directory dmake: Error code 129, while making 'build_all' ---*TG_SLO.MK*---
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 is probably from MS Visual C++ V7.0, see issue 8123.
No, sorry I was wrong. The problem is here: ============= Building project freetype ============= /cygdrive/e/OO643C/oo_643c_src/freetype ^^^^^^^^^^^ and not e:/ You are using a cygwin build dmake.exe! This is not yet supported, nor it is working. Get a fresh dmake/ directory from the source archiv and build the dmake.exe by starting winenv.bat in your 4nt shell.
No, I used 4NT to do so.... Cygwin is only used for configure.... One of my friends has successfully compiled one with a lot of manual corrections: 1. some tarball cannot be extracted during dmake before "patch", there are some problems on the path like "/" and "\" and those ".." is excessive or insufficient.... a manual extraction helps to remove the problem before dmake 2. some resource files cannot be generated by the script, since the make directory script does not work 3. some of the project file for visual C++ cannot be made correctly, the command is like type xxx.map | awk -f ........ > .....wx../*.dxp cannot be executed correctly. One has to make it cat and to replace "/" with "\" and some files are missing in the source tarball and has to cvs update manually. Comment? ------- Additional Comments From Volker Quetschke 2002-12-03 08:49 PST ------- No, sorry I was wrong. The problem is here: ============= Building project freetype ============= /cygdrive/e/OO643C/oo_643c_src/freetype ^^^^^^^^^^^ and not e:/ You are using a cygwin build dmake.exe! This is not yet supported, nor it is working. Get a fresh dmake/ directory from the source archiv and build the dmake.exe by starting winenv.bat in your 4nt shell.
>No, I used 4NT to do so.... Cygwin is only used for configure.... Yes, sorry again, I just realized that the 4nt build also writes Posix style paths. >One of my friends has successfully compiled one with a lot of manual >corrections: I do that routinely *WITHOUT* modifications. The only diference is, that I use the OO643C sources from cvs. I never tried the source tarball, but I will do this evening! I still think there is a problem in your configuration, can you please attach your winenv.bat so that I can search for differences. It would also be usefull if you do a "cygcheck -sv" in your cygwin bash and also post the output here. >1., 2. and 3. I never had to do this. >and some files are missing in the source tarball and has to cvs update manually. Which files do you update? Comment? See above ;-) Volker
1) I'll attached my winenv.bat in the next msg. 2) I'll attached my result from cygcheck -sv in the next next msg. :) 3) For which file to be cvs update, I'm now reproducing all the steps with the help of my friend, so I will report back later. Thanks a lot! ------ Additional Comments From Volker Quetschke 2002-12-04 01:24 PST ------- >No, I used 4NT to do so.... Cygwin is only used for configure.... Yes, sorry again, I just realized that the 4nt build also writes Posix style paths. >One of my friends has successfully compiled one with a lot of manual >corrections: I do that routinely *WITHOUT* modifications. The only diference is, that I use the OO643C sources from cvs. I never tried the source tarball, but I will do this evening! I still think there is a problem in your configuration, can you please attach your winenv.bat so that I can search for differences. It would also be usefull if you do a "cygcheck -sv" in your cygwin bash and also post the output here. >1., 2. and 3. I never had to do this. >and some files are missing in the source tarball and has to cvs update manually. Which files do you update? Comment? See above ;-) Volker
Created attachment 3910 [details] My cygcheck -sv
Created attachment 3911 [details] My winenv.bat
Hi, I didn't find anything special in your cygcheck output. Nearly the same as in my setup. But two things: 1. Who put the --- alias awk gawk --- line in your winenv.bat? It should not be there. But this brought me to: 2. Did you remove the symlinks for awk.exe, tar.exe and gunzip.exe? I know tha cygwin creates symlinks for this files during installation, and here I get an error popup when I call a cygwin symlink from 4NT, but maybe that is system dependent. Tell me what: ls -l /bin/awk.exe ls -l /bin/tar.exe ls -l /bin/gunzip.exe show from your bash shell. If they *ARE* symlinks, then remove the link, and copy the program to the name of the link, eg: rm /bin/awk.exe cp /bin/gawk.exe /bin/awk.exe Hope this helps, Volker
> alias awk gawk > line in your winenv.bat? It should not be there. Alright, since I found that there's no awk there and that's why I do this. Upon hearing your advice, I believe that 4NT will not be able to reference the symbolic links created by Cygwin and that's why the awk does not work. I've followed your comment on replacing the symbolic links by copying. Using this method, I no longer need to untar those tarball manually in order to extract them. But the problem on every cat *.map | awk -f ...xxx > *.dxp (or something alike) persists. There's also unresolved symbol in those *uno* module in, I suppose, near the completion stage of those modules. Any hint? Thanks a lot!
Hi! >Upon hearing your advice, I believe that 4NT will not be able to >reference the symbolic links created by Cygwin and that's why >the awk does not work. I know that it cannot and this has to be documented on the Build Instructions page. I will start an issue soon. >Using this method, I no longer need to untar those >tarball manually in order to extract them. Good. >But the problem on every cat *.map | awk -f ...xxx > *.dxp (or >something alike) persists. Can you please send us the error output where your build fails in this case. I must see what and where it fails, have a look at the makefiles to get an idea where the problem might be. Volker
set this issue to fixed, please feel free to open new issues if there are problems left. here are too many different problems and solution discussed.
verified.
close issue.