Re: [Mingw-users] Cross-compiling for Win32 on Linux - gettext usable??.

[John B. <joh...@ho...>]

David Bruce wrote:

> On Wednesday 05 December 2007 05:02:20 am John Brown wrote:
>> David Bruce wrote:
>
>> Your post was very vague. It is never enough to say "It's not working!
>> Help!", so:
>
> Of course - I was first trying to determine whether this is an appropriat=
e
> list for my questions.

OK.

>>
>> 1) When you say that you "have not been able to get the crossbuild to
>> work", what do you mean, exactly?
>
> The windows build compiles without problems. It runs fine in English, or =
if I
> set the language to something like Swahili that isn't a translation for m=
y
> program. If I use "set LANG=3Dxx_XX" to set the language to anything incl=
uded
> in my collection of .mo files, the program terminates immediately at the
> first call of gettext(). Windows displays a dialogue saying my program
> terminated unexpectedly, and nothing helpful gets written to the stderr.t=
xt
> file.

************************************************************************
In that case, download mingw-utils-0.3 at http://sourceforge.net/project/sh=
owfiles.php?group_id=3D2435&package_id=3D82721

Install Dr. Mingw. 'Make distclean' and re-build your program with debuggin=
g info.
When it crashes, Dr. MinGW will show the call stack and registers. Maybe th=
at will
help.

One possibility may be that gettext does not know where to find your .mo fi=
les.
It could be looking in a path like /usr/local/.../LC_MESSAGES (derived from=
 --prefix)
that might be hard-coded into gettext. Of course, such a path does not exis=
t on
Windows. There is probably an environment variable that you can set to tell
gettext where to find the .mo files.

>
>> 2) Did you compile gettext yourself with your cross-compiler? Of course,
>> your cross-compiler cannot link to your Debian gettext.
>
> My program has its own intl directory (created by gettextize), which cont=
ains
> gettext() and I followed the gettext docs to tell the build to use it rat=
her
> than a separate libintl. However, I haven't done anything in the build to
> link in libiconv, which I think may be the problem. Just copying icon.dll=
 to
> the same folder as the rest of the dll's used by my program (SDL.dll, etc=
)
> did not fix the problem.

I don't think that that is your problem. If -liconv was required, but not i=
n the
command line, the program would not have linked.  If libiconv.dll was requi=
red
but missing, Windows would have told you right at the start.

_________________________________________________________________
You keep typing, we keep giving. Download Messenger and join the i=92m Init=
iative now.
http://im.live.com/messenger/im/home/?source=3DTAGLM=