Apache OpenOffice (AOO) Bugzilla – Issue 18098
Build fails in i18npool/source/localedata/data
Last modified: 2003-08-25 11:47:00 UTC
With 1.1 RC3, checked out from CVS at 9 august 2003, deja vu: see isssue 14984. /cygdrive/c/ooo_11rc3_src/i18npool/source/localedata/data guw.pl ../../../wntmsci9.pro/bin/saxparser en_AU en_AU.xml ../../../wntmsci9.pro /misc/localedata_en_AU.cxx ../../../wntmsci9.pro/bin/localedata.rdb /cygdrive/c/ ooo_11rc3_src/solver/645/wntmsci9.pro/bin/types.rdb Command: ../../../wntmsci9.pro/bin/saxparser Exception on createRegistryServiceFactory dmake: Error code 1, while making '../../../wntmsci9.pro/misc/localedata_en_AU. cxx' echo: No match. ERROR: Error 65280 occurred while making /cygdrive/c/ooo_11rc3_src/i18npool/sour ce/localedata/data dmake: Error code 1, while making 'build_all' echo: No match. The tools setup is exactly the same as I use for 1.1RC2 where I don't have this problem. Initially I had SCR_ROOT with a period in its name, unlike that for RC2, but changing this made no difference.
*** Issue 18099 has been marked as a duplicate of this issue. ***
Hmm, strange. I cannot reproduce. Simon, can you please uncomment the #$debug_light="true"; line in solenv/bin/guw.pl. This will write the executed command with parameters to stdout, we'll see what saxparser gets as arguments.
/cygdrive/c/ooo_11rc3_src/i18npool/source/localedata/data guw.pl ../../../wntmsci9.pro/bin/saxparser en_AU en_AU.xml ../../../wntmsci9.pro /misc/localedata_en_AU.cxx ../../../wntmsci9.pro/bin/localedata.rdb /c ygdrive/c/ ooo_11rc3_src/solver/645/wntmsci9.pro/bin/types.rdb Command: ../../../wntmsci9.pro/bin/saxparser --------------------- Execute: ../../../wntmsci9.pro/bin/saxparser en_AU en_AU.xml ..\..\..\wntmsci9.p ro\misc\localedata_en_AU.cxx ..\..\..\wntmsci9.pro\bin\localedata.rdb c:\ooo_11r c3_src\solver\645\wntmsci9.pro\bin\types.rdb ---------------- Exception on createRegistryServiceFactory dmake: Error code 1, while making '../../../wntmsci9.pro/misc/localedata_en_AU. cxx'
The parameters look ok, can you please check if all files really exist.
I think so. Any more files you want me to check? [Simon@max ...ooo_11rc3_src/i18npool]$ ls wntmsci9.pro/bin/ dict_ja.dll dict_zh.pdb gendict.exe i18nsearch.pdb dict_ja.pdb genconv_dict.exe gendict.pdb saxparser.exe dict_zh.dll genconv_dict.pdb i18nsearch.dll saxparser.pdb [Simon@max ...ooo_11rc3_src/i18npool] $ls ../solver/645/wntmsci9.pro/bin/types.rdb /cygdrive/c/ooo_11rc3_src/solver/645/wntmsci9.pro/bin/types.rdb [Simon@max ...ooo_11rc3_src/i18npool]$ ls source/localedata/data/en_AU.xml source/localedata/data/en_AU.xml
>[Simon@max ...ooo_11rc3_src/i18npool]$ ls wntmsci9.pro/bin/ >dict_ja.dll dict_zh.pdb gendict.exe i18nsearch.pdb >dict_ja.pdb genconv_dict.exe gendict.pdb saxparser.exe >dict_zh.dll genconv_dict.pdb i18nsearch.dll saxparser.pdb localedata.rdb is missing, but I don't know if I have it :-( I recently started a fresh build, so all my wntmsci?.pro are empty now. I will check once the build passes i18npool.
OK, the build passed i18npool, and I have: $ ls wntmsci9.pro/bin/ dict_ja.dll* i18npool645mi.dll* localedata_es.pdb* dict_ja.pdb* i18npool645mi.pdb* localedata_euro.dll* dict_zh.dll* i18nsearch.dll* localedata_euro.pdb* dict_zh.pdb* i18nsearch.pdb* localedata_others.dll* genconv_dict.exe* localedata.rdb* localedata_others.pdb* genconv_dict.pdb* localedata_en.dll* saxparser.exe* gendict.exe* localedata_en.pdb* saxparser.pdb* gendict.pdb* localedata_es.dll* So it seems you're missing localedata.rdb, lets ask the l10n people if they know what's going on here. When/where is localedata.rdb created? What is saxparser doing? I confirm this issue to get some attention ;-)
I downloaded the RC3 sources to build from scratch, but I still run into the same problem. The file localedata.rdb does not exist in the rc3 solver, so I copied it from rc2 into i18npool\wntmsci9.pro\bin. It doesn't make any difference (is this file actually an input file in the command?) I also copied saxparser.exe from rc2: it does not make any difference. For reference, my configure parameters were: ./configure --with-use-shell=tcsh --with-2003-psdk --with-cl- home=/cygdrive/c/progra~1/micros~2/vc98 --with-jdk- home=/cygdrive/c/j2sdk1.4.1_03 --with-asm-home=/cygdrive/c/oo_util1.1 --with-ant-home=/cygdrive/c/oo_util/apache-ant-1.5.3-1 and I am quite sure I have correct versions of all the tools according to the build guide (after all, used it to build RC2 without problems!!!) Any help would be very welcome now.
Using 4NT shell, the build failed at the same point, so it's apparently not tcsh related.
AFAIK, is just a required output file for the "saxparser" which gets overwritten for each call anyway... since this is also a problem or multiprocess builds, try out the changes in Rev. 1.20.6.2. maybe it gives at least some hints where to look further.
Updating that makefile did not help. Other things I tried to find the problem: I replaced the input files for saxparser with the versions from the 1.1rc2 tree (which had built OK) and ran saxparser; it gave the same error. Then I replaced saxparser.exe with the one from the 1.1rc2 tree, and this also gave this error. I can't think of anything else than that the error is in a file that is dynamically linked by saxparser. The exception occurs in a function call createRegistryServiceFactory() for which I found some code on line 649 in cppuhelper/source/servicefactory.cxx, but if I add a printf() at the very start of this function, run build and deliver in cppuhelper, and build i18npool, I don't see any output coming from this printf(). So I'm wondering if I am doing something wrong or if said function is to be found somewhere else. Suggestions where to look next are very welcome.
Here's more. The reason why I could not see the printf() output, is because saxparser does NOT load the proper cppuhelper3msc.dll from somewhere in the source tree, but from c:/Windows/System! This means it is not the correct version, it's one installed by some previous version of OOo. If I replace it with the one from cppuhelper/wntmsci9.pro/bin, then at least I get the output of the printf() I added. I can now determine that the createRegistryServiceFactory() function crashes in the first function it calls, bootstrapInitialSF(), which I haven't found a source file for, but which is probably in another DLL that is also called from the wrong place and of the wrong version... How does saxparser (and other build programs) determine the location that it loads the DLL's from???
Hi Simon! > How does saxparser (and other build programs) determine the location > that it loads the DLL's from??? From the PATH variable. I think you found an important problem! I never run into it, because my build scripts allways do something like: # Speed up build, remove pathes. export PATH=/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT cd config_office ./configure ... Can you try if this helps in your case?
Hi Volker, I'll try it in the evening, because at the moment I'm just quickly checking my email before going to work.
DL->Simon: just reassigned.
I tried this, but the build environment now missed paths to the SDK, msdev, etc. and did not get very far. Anyway, normally when starting bash: PATH='/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Perl/bin/:/cygdrive/d/P erl/bin/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/ WINDOWS/System32/Wbem:/usr/bin:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools/WinNT:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio/VC98/bin:/cygdrive/c/util' and in tcsh, after running winenv.set, PATH=.:/cygdrive/g/oo_11rc3_src/solver/645/wntmsci9.pro/bin:/cygdrive/ g/oo_11rc3_src/solenv/bin:/cygdrive/g/oo_11rc3_src/solenv/wntmsci9/bin :/cygdrive/c/j2sdk1.4.1_03/bin:/cygdrive/c/j2sdk1.4.1_03/jre/bin/clien t:/cygdrive/c/progra~1/micros~2/vc98/bin:/cygdrive/c/oo_util1.1:/cygdr ive/c/WINDOWS:/usr/local/bin:/usr/bin:/bin:/cygdrive/c/Perl/bin/:/cygd rive/d/Perl/bin/:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cyg drive/c/WINDOWS/System32/Wbem:/usr/bin:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools/WinNT:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/MSDev98/Bin:/cygdrive/c/Program Files/Microsoft Visual Studio/Common/Tools:/cygdrive/c/Program Files/Microsoft Visual Studio/VC98/bin:/cygdrive/c/util So the PATH does include c:\Windows\ and c:\Windows\system32 but not c:\windows\system ! Are you sure it's the PATH that is used to find the locations of dll's?
"With both implicit and explicit linking, Windows first searches the set of pre-installed DLLs such as the performance library (KERNEL32.DLL) and the security library (USER32.DLL). Windows then searches for the DLLs in the following sequence: 1. The directory where the executable module for the current process is located. 2. The current directory. 3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory. 4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory. 5. The directories listed in the PATH environment variable." See: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/vccore98/HTML/_core_the_search_path_used_by_windows_to_locate_a_dll .asp As the DLL is executed from c:/windows/system, while that directory is not in the PATH, it would be safe to conclude that it is searched before trying the PATH.
Hi Simon, next time I post my complete build script snippet ;-) export PATH=/bin:/cygdrive/c/WINNT/system32:/cygdrive/c/WINNT cd config_office ./configure --with-cl-home=/cygdrive/c/Programme/MSVS6/VC98 --with-mspdb-path="/cygdrive/c/Programme/Microsoft Visual Studio/Common/msdev98/bin" --with-asm-home=/cygdrive/c/mas/bin/win98 --with-jdk-home=/cygdrive/c/j2sdk1.4.1_02 --with-use-shell=tcsh--with-use-shell=tcsh --with-psdk-home=/cygdrive/c/psdk02_2003 --with-2003-psdk --enable-crashdump (For MSVC 6) With this I have no problems that programs are missing/not found. But this doesn't help with your problem with wrong dlls used. I checked, and I don't have cppuhelper in c:\WINNT\System I don't have a file newer than 22.07.2002 in that directory, no file from Openoffice. This is on the machine I compile OOo with MSVC 6. Huh? P.S. I don't have cppuhelper3msc.dll at all below c:\WINNT\
Maybe the multi user install puts those dll's there?
I renamed the following files in C:\WINDOWS\SYSTEM cppu3.dll cppuhelper3MSC.dll sal3.dll salhelper3MSC.dll tl645mi.dll ucbhelper2MSC.dll uwinapi.dll vos3MSC.dll after which the i18npool project built to completion. These files were put there around the time I installed 1.1RC or 1.1RC2. I have tried both the -net install and the non -net install. In any case, building with older versions of these files in C:\WINDOWS\System does not work or may result in a bad build. Maybe the build guide should contain a warning, and/or the config script should check on the existence of these files?
Dirk Voelzke assured me that the installation script is supposed to never copy any dll's into the Windows system directory. Unfortunately it's difficult to check what happened. I'll close this issue now, with the intention to check if any of my builds do this, raising a new issue when appropriate.
DL: Closed