Menu
▾
▴
#1500 gettextize refers to missing files in
pending
Task
none
Unknown
False
2018-12-12
2011-01-08
No
I'm having problems running gettextize on a project.
I've installed MinGW and Msys via the mingw-get-inst-20101030.exe package. I selected the option to use more recent packages than those in the installer's packaged list.
Output of "gettextize --no-changelog"
Sorry, not used to the tracker here. I seem to have committed the ticket before I was finished documenting it. Please wait...
I've redone everything w/ a fresh install and after babying some environment variables. Although I have a problem which is kind of related, it doesn't seem to be from gettextize.
That being said, at least let me document something strange which did occur.
Detailed output is in the attachment. It seems that gettextize looks for some m4 macros, and is unable to find them. This doesn't seem to break things, but it at least makes me a bit concerned.
Specifically, gettextize is trying to copy files from C:/msys/1.0/var/tmp/gettext-reloc-yA4108/mingw/share/aclocal/. I checked the gettextize source, and the path is specified directly in the vars at the top of the script. (msys, by the way, is at c:/mingw/msys on my system, so it's a total miss...)
As I say, this seems to be a "works for me" issue even though the m4 macros are not found. But in case investigation is desired, here's more details:
-----
gettextize modification date: 2009-JUL-26, 9:20 AM
Gettext version info:
/mingw/bin/gettextize (GNU gettext-tools) 0.17
Copyright (C) 1995-1998, 2000-2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Ulrich Drepper
MinGW shell "uname -a", in case it's relevant:
MINGW32_NT-6.1 CORE 1.0.16(0.48/3/2) 2010-09-29 00:07 i686 Msysw
This is a consequence of the "relocation" support built in to gettext (and libiconv). This facility is SUPPOSED to allow for the end user -- you -- to install the gettext packages anywhere on your disk and gettext should Just Work, regardless of the path I used when I built them. In fact, to work properly, the build path should be a one-time-use directory unlikely to exist on any end-user's machine: hence, the weird /var/tmp/gettext-reloc-nnnnn/ path.
What is SUPPOSED to happen is that the gettextize script compares its own, current path (C:/MinGW/bin/ maybe?) to the "expected" installation path, and then replaces substitutes the correct prefix into all file accesses: e.g. it should automatically turn the "get file from C:/msys/1.0/var/tmp/gettext-reloc-yA4108/mingw/share/aclocal" into C:/MinGW/share/aclocal/. But obviously that is not happening.
There have been some changes in the relocation code in more recent gettexts. I'll build a new gettext-0.18.1 (or newer) eventually, and hopefully that version will work better.
Charles Wilson surely isn't going to follow this up now, since he is no longer an active project contributor; Cesar, would you care to comment?