intl.dll vs. libintl.dll

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello fellow Gtk users!

I'm a developer for an open source project called GtkRadiant, which is an editing tool for Quake 3 maps (pretty exciting I must say!).  I'm currently attempting to overhaul the build process for the Windows builds.  In particular, I'm in the process of getting the GtkRadiant code to compile against a recent version of Gtk+.

I am having a very particular problem with libintl.  To demonstrate my problem, I have created a very small program that demonstrates the problem in as few lines of code as possible.  My code looks like this:


==============================
#include <stdio.h>
#include <libintl.h>

int main(int argc, char *argv[])
{
        char buf[10];
        snprintf(buf, 10, "%i", 333);
        printf("%s\n", buf);
        return 0;
}
==============================


In the actual GtkRadiant project, the reason why libintl is being included is indirectly as a result of an glib/gi18n.h include (side effect include due to gi18n.h).

I compile the code snippet above in Visual C++ 2008 Express Edition.  In fact, I have an SVN project for this:

  svn://porky.nerius.com/repos/libintl-prob-example

If you check out this project, run the script libintl-prob-example/setup.sh in MSYS terminal emulator, which will download Gtk+ and place it in the parent directory, and copy dll files to the install folder.  Then compile the project in VC++ 2008.

The particular version of Gtk+ I'm using is the file available from http://ftp.gnome.org/pub/gnome/binaries/win32/gtk+/2.16/gtk+-bundle_2.16.6-20100912_win32.zip .

The problem with my example program is that it tries to load libintl.dll when in fact the file is named intl.dll.  When I tried to fix this problem in GtkRadiant previously, I simply renamed intl.dll to libintl.dll, and this was a catalyst for all sorts of other problems (if I recall correctly, other modules were trying to load intl.dll).

Is gtk+-bundle_2.16.6-20100912_win32.zip built improperly?  How do I address this issue in an elegant manner?  I don't want to try the newest 2.22 bundle because of concerns that my GtkGlExt might not work anymore; from the documentation it seems that 2.16 might be a bit more tried and tested.

- Rambetter
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux