Apache OpenOffice (AOO) Bugzilla – Issue 16650
localize.exe breaks in w32 w/ tcsh build, OO11RC2
Last modified: 2003-10-22 06:55:35 UTC
After sucessfully build on milestone cws_srx645_ooorc2 from a totally clean checkout, localize.exe breaks with the following message AppName localize.exe AppVer 0.0.0.0 ModName tl645mi.dll ModVer 7.0.0.8651 offset 002d058 in the same tcsh shell as dmake was run Localize.exe was invoked with the following command setenv RES_PORTBR TRUE setenv L10N_framework pt-BR cd /solver/645/wnt(..)/bin/ localize -m -i pt-BR -l 55 -f (..)mylocalizationfile.txt Invoking localize.exe under a 4NT shell with same syntax and environment variables is OK, even if localize.exe was built in tcsh shell Olivier
Created attachment 7527 [details] error report that would be be sent to Microsoft
reassigned.
> After sucessfully build on milestone cws_srx645_ooorc2 from a totally clean > checkout, localize.exe breaks with the following message > AppName localize.exe > AppVer 0.0.0.0 > ModName tl645mi.dll > ModVer 7.0.0.8651 offset 002d058 > > in the same tcsh shell as dmake was run > Localize.exe was invoked with the following command > setenv RES_PORTBR TRUE > setenv L10N_framework pt-BR > cd /solver/645/wnt(..)/bin/ > localize -m -i pt-BR -l 55 -f (..)mylocalizationfile.txt What is the exact format of "(..)mylocalizationfile.txt"? POSIX od DOS style? I'm sure the problem are some environment variables in POSIX format. localize is a native W32 application, even when build in W32-tcsh environment. > Invoking localize.exe under a 4NT shell with same syntax and environment > variables is OK, even if localize.exe was built in tcsh shell Yes, but winenv.bat has all variables in DOS format, that is expected to work. vq->nf: Which env variables are used by localize?
Created attachment 7535 [details] merge file for pt-BR
Hello Volker the syntax of localize.exe is (in tcsh under cygwin) localize -m -i pt-BR -l 55 -f /oo110/br20.txt where br20.txt is the merge file. (I forgot to mention I used VS.NET compiler, if that matters) I am attaching the file br20.txt just in case. Regards Olivier
Hi Olivier! > the syntax of localize.exe is (in tcsh under cygwin) > localize -m -i pt-BR -l 55 -f /oo110/br20.txt Ahh, that cannot work, because localize cannot handle POSIX style paths. Can you please try: $ localize -m -i pt-BR -l 55 -f c:\\oo110\\br20.txt Well, you know what I mean, the correct DOS style path, but use double backslashes. > (I forgot to mention I used VS.NET compiler, if that matters) No, that will be the compiler used for binary releases anyway.
Hi Volker. No luck. Same error. Here is a copy of the command prompt ++++++++++ Olivier@liberty-builder /oo110/ooo_1.1beta2_src $ tcsh [Olivier@liberty-builder /oo110/ooo_1.1beta2_src]$ source winenv.set [Olivier@liberty-builder /oo110/ooo_1.1beta2_src]$ cd solver/645/wntmsci8.pro/bin [Olivier@liberty-builder ...wntmsci8.pro/bin]$ localize -m -i pt-BR -l 55 -f c:\\cygwin\\oo110\\br20.txt ============================================================ Current settings: ============================================================ Mode: merge Workspace: SRX645 Source tree: \oo110\ooo_1.1beta2_src Languages: 55 ISO code (99): pt-BR Filename: c:\cygwin\oo110\br20.txt ============================================================ Reading database /OO110/OOO_1.1BETA2_SRC/SOLENV/CONFIG/STAND.LST ... [Olivier@liberty-builder ...wntmsci8.pro/bin]$ +++++++ Regards Olivier
Hi Olivier! > No luck. Same error. But usefull debuging information. ;-) > Source tree: \oo110\ooo_1.1beta2_src I guess localize reads the SRC_ROOT variable from the environment. Lets try something ugly: ;-) $ guw.pl -env localize -m -i pt-BR -l 55 -f /oo110/br20.txt The guw.pl is the "great unified wrapper" for POSIX -> DOS and the env flag converts also some environment variables. Please try.
Hi Well, bravo!. Absolutely no glitch with guw.pl, which looks cute instead of ugly :-) After invoking guw.pl as indicated, I have 15 minutes of screen rolling, ending in +++++++ (.....) TransEx 3.1 Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. ======================================================================== Processing File common.src ... Scanning File c:\DOCUME~1\Olivier\CONFIG~1\Temp\svpe5.tmp ... File detection: Version 2.0 detected! Merging ... =================================== ##### C:\cygwin\oo110\ooo_1.1beta2_src\wizards\source\webwizard\webwizar.src ### ## TransEx 3.1 Copyright 2000 Sun Microsystems, Inc. All Rights Reserved. ======================================================================== Processing File webwizar.src ... Scanning File c:\DOCUME~1\Olivier\CONFIG~1\Temp\svpe5.tmp ... File detection: Version 2.0 detected! Merging ... =================================== [Olivier@liberty-builder /oo110/ooo_1.1beta2_src]$ +++++++++ which means it worked. Thank you. Olivier P.S. localize is a program that runs transex.exe on a bunch of localizable files.
As Volker mentioned, we have to take a deeper look to some of the environment variables, I guess. First one I have in mind is STAR_STANDLST This points to the stand.lst which contains workspace definitions and module names. The output >Reading database /OO110/OOO_1.1BETA2_SRC/SOLENV/CONFIG/STAND.LST ... indicates that this has to be set in windows/dos format. The stand.lst is used by localize to get the list of valid modules. The source for this is withing tools/bootstrp/appdef.cxx in function const char* GetDefStandList() called by main() within transex3/source/localize.cxx
Hi, Trying to re-run localize.exe with guw.pl now breaks and gives the same error as reported above. I am back to the first situation. Olivier
Am I the ownwer of this issue? I barely can do anything on it... Olivier
mh->nf: please give Oliver some more detailed info how to proceed.
fixed
Duplicate to i15224 which is also fixed -> closed both