I am needing some help with libiconv, the liks eventually lead me to this forum... if this is the wrong location to seek help please direct me to the correct location.
I am trying to build a vc++ program on windows XP, I want to make use of libiconv to do some file conversions. I have inluced iconv.h and visual studio finds it correctly. I seem to be getting the following unresolved externals when I try to build:
unresolved external symbol _libiconv_close referenced in function _main
unresolved external symbol _libiconv_open referenced in function _main
I would greatly appreciate any tips/advice people have in regards to this issue. I'm new to using the GnuWin32 libraries so maybe I'm just missing something that is broad and general to the collection as a whole. The iconv app that comes in bin works fine though. I could always just make a call to that program but I consider this to be a dirty approach. I'd rather it just be included into the application itself.
Thanks for you time
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
win_iconv compiled in fine, thanks for suggesting it. I was wondering if there are any examples that you may know of that I can look over. I am having some difficulty getting it to convert from ISO-8859-1 to UTF-8, it doesn't return the error code it just returns 0. It may just be the input ( garbage in, garbage out ), but some examples would help me to understand if I'm incorrectly using the functions.
It isn't sufficient to just include the iconv.h header; you also have to tell the linker to use the associated library.
I'm not familiar with what is included in the GnuWin32 library package, since I use the MinGW variant of libiconv. This one offers the choice of linking either statically, to libiconv.a, (equivalent to iconv.lib), or to a DLL variant, either directly to the DLL, or via an import library. I expect the GnuWin32 variant offers similar features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've statically linked the libiconv.a which took care of the unresolved errors for the iconv functions. I am now getting a
unresolved external symbol __alloca referenced in function _libiconvlist
error, so I think I'm missing a required library that libiconv depends on. I'll post back if I figure it out, but thanks for the response it helped a lot.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You must also link to libgw32c.a (http://gnuwin32.sourceforge.net/packages/libgw32c.htm). Hopefully, an easier solution will be available with the next release of libiconv. You might also try the port of libiconv-1.9.1 at http://ftp.gnu.org/gnu/libiconv (libiconv-1.9.1.bin.woe32.zip).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2008-03-17
May I recommend the win_iconv package by Yukihiro Nakadaira, which implements iconv() by using the Win32 API. It provides conversion between the encodings for which there exists a corresponding code page. The code pages available on each Windows machine varies I guess, depending on choices made when installing Windows. As it doesn't contain any encoding tables itself, it is much smaller than GNU libiconv. It is not exactly identical in functionality to GNU libiconv (for instance, it lacks the Java and C99 "encodings", and interprets UCS-2 as an alias for UTF-16), but should be good enough for most uses. Get http://ftp.acc.umu.se/pub/GNOME/binaries/win32/dependencies/win_iconv-tml-20080317.zip .
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Somewhat incongruously perhaps, the bin package provides the development headers and libraries, and the man pages, together with the iconv.exe tool, but it doesn't include the DLLs, which are in the dll package. (I'm not even sure if the iconv.exe provided can run without the DLLs also being present; I guess I should review this packaging structure with the gentleman who prepared these packages for us).
Tor Lillqvist's suggestion for an alternative implementation, (Yukihiro Nakadaira's), would also be worth a look.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yea I was playing around with the iconv.exe tool and it does require that the dlls be available. At least the version that I have does. Which I installed via the setup program. I think it was 1.9.2-1. It did come with the dlls though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, we are talking about two different distributions; you are using the GnuWin32 package, while I was referring to the MinGW one. However, I just installed that MinGW bin package into a clean tree, without the DLLs present, or in the PATH; it does need the DLLs to also be installed, to be able to run iconv.exe, so there would seem to be a definite need to rationalise the MinGW package structure.
Do note that, using 1.9.2-1, there are some quite nasty Win32 specific bugs just waiting to jump out and bite you. The one I particularly noticed arose when processing data from a character set which cannot be fully represented in the active system code page, converting through the wchar_t domain and back; this may result in data corruption, because those code points which have no representation in the system code page throw an invalid conversion exception, which, depending on how you handle it, either terminates processing, or drops part of the data stream; this is fixed in MinGW's 1.11-1 release, (and in GNU libiconv's CVS since I reported it, so presumably in stock libiconv-1.12).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Greetings,
I am needing some help with libiconv, the liks eventually lead me to this forum... if this is the wrong location to seek help please direct me to the correct location.
I am trying to build a vc++ program on windows XP, I want to make use of libiconv to do some file conversions. I have inluced iconv.h and visual studio finds it correctly. I seem to be getting the following unresolved externals when I try to build:
unresolved external symbol _libiconv_close referenced in function _main
unresolved external symbol _libiconv_open referenced in function _main
I would greatly appreciate any tips/advice people have in regards to this issue. I'm new to using the GnuWin32 libraries so maybe I'm just missing something that is broad and general to the collection as a whole. The iconv app that comes in bin works fine though. I could always just make a call to that program but I consider this to be a dirty approach. I'd rather it just be included into the application itself.
Thanks for you time
win_iconv compiled in fine, thanks for suggesting it. I was wondering if there are any examples that you may know of that I can look over. I am having some difficulty getting it to convert from ISO-8859-1 to UTF-8, it doesn't return the error code it just returns 0. It may just be the input ( garbage in, garbage out ), but some examples would help me to understand if I'm incorrectly using the functions.
This is my current code:
bool convertToUTF8( std::string src, std::string out, std::string srcEnc="windows-1252" )
{
FILE* inputText = fopen( src.c_str(), "rb" );
fseek( inputText, 0, SEEK_END );
long fileSize = ftell( inputText );
fseek( inputText, 0, SEEK_SET );
char inFileBuf = new char[fileSize+1];
long bytes_read = fread( (void)inFileBuf, sizeof(char), fileSize, inputText );
fclose( inputText );
if( bytes_read != fileSize )
return false;
inFileBuf[fileSize] = '\0';
char* outFileBuf = new char[fileSize+1];
iconv_t cd;
cd = iconv_open( "UTF-8", srcEnc.c_str() );
unsigned int iconvResult = iconv( cd, (const char)&inFileBuf, (unsigned int)&fileSize, &outFileBuf, (unsigned int)&fileSize );
iconv_close( cd );
if( iconvResult != sizeof(-1) && iconvResult != 0 )
{
FILE outFile = _wfopen( (wchar_t)out.c_str(), L"wb" );
fwrite( (void*)outFileBuf, sizeof(wchar_t), fileSize, outFile );
fclose( outFile );
return true;
}
return false;
}
It isn't sufficient to just include the iconv.h header; you also have to tell the linker to use the associated library.
I'm not familiar with what is included in the GnuWin32 library package, since I use the MinGW variant of libiconv. This one offers the choice of linking either statically, to libiconv.a, (equivalent to iconv.lib), or to a DLL variant, either directly to the DLL, or via an import library. I expect the GnuWin32 variant offers similar features.
I've statically linked the libiconv.a which took care of the unresolved errors for the iconv functions. I am now getting a
unresolved external symbol __alloca referenced in function _libiconvlist
error, so I think I'm missing a required library that libiconv depends on. I'll post back if I figure it out, but thanks for the response it helped a lot.
You must also link to libgw32c.a (http://gnuwin32.sourceforge.net/packages/libgw32c.htm). Hopefully, an easier solution will be available with the next release of libiconv. You might also try the port of libiconv-1.9.1 at http://ftp.gnu.org/gnu/libiconv (libiconv-1.9.1.bin.woe32.zip).
May I recommend the win_iconv package by Yukihiro Nakadaira, which implements iconv() by using the Win32 API. It provides conversion between the encodings for which there exists a corresponding code page. The code pages available on each Windows machine varies I guess, depending on choices made when installing Windows. As it doesn't contain any encoding tables itself, it is much smaller than GNU libiconv. It is not exactly identical in functionality to GNU libiconv (for instance, it lacks the Java and C99 "encodings", and interprets UCS-2 as an alias for UTF-16), but should be good enough for most uses. Get http://ftp.acc.umu.se/pub/GNOME/binaries/win32/dependencies/win_iconv-tml-20080317.zip .
I wouldn't recommend 1.9.1, which is very old, and buggy wrt Win32. I discovered a particularly nasty bug about a year ago, in 1.11, which has since been fixed in CVS. Although I built my own copy from source, and I didn't package these myself, I believe that the MinGW build of libiconv-1.11-1 includes the patch to fix this:
http://downloads.sourceforge.net/mingw/libiconv-1.11-1-bin.tar.bz2
http://downloads.sourceforge.net/mingw/libiconv-1.11-1-dll.tar.bz2
http://downloads.sourceforge.net/mingw/libiconv-1.11-1-src.tar.bz2
Somewhat incongruously perhaps, the bin package provides the development headers and libraries, and the man pages, together with the iconv.exe tool, but it doesn't include the DLLs, which are in the dll package. (I'm not even sure if the iconv.exe provided can run without the DLLs also being present; I guess I should review this packaging structure with the gentleman who prepared these packages for us).
Tor Lillqvist's suggestion for an alternative implementation, (Yukihiro Nakadaira's), would also be worth a look.
Yea I was playing around with the iconv.exe tool and it does require that the dlls be available. At least the version that I have does. Which I installed via the setup program. I think it was 1.9.2-1. It did come with the dlls though.
Well, we are talking about two different distributions; you are using the GnuWin32 package, while I was referring to the MinGW one. However, I just installed that MinGW bin package into a clean tree, without the DLLs present, or in the PATH; it does need the DLLs to also be installed, to be able to run iconv.exe, so there would seem to be a definite need to rationalise the MinGW package structure.
Do note that, using 1.9.2-1, there are some quite nasty Win32 specific bugs just waiting to jump out and bite you. The one I particularly noticed arose when processing data from a character set which cannot be fully represented in the active system code page, converting through the wchar_t domain and back; this may result in data corruption, because those code points which have no representation in the system code page throw an invalid conversion exception, which, depending on how you handle it, either terminates processing, or drops part of the data stream; this is fixed in MinGW's 1.11-1 release, (and in GNU libiconv's CVS since I reported it, so presumably in stock libiconv-1.12).