[Locale] On Mac OS X 10.6 fails to find iconv
Hello, I need a help from Mac OS X users, I have many faults on Darwin: http://beta.boost.org/development/tests/trunk/developer/locale.html Where all GCC's are related to inability to find iconv for some reason. On my darwin 8.01 x86 I have no problems to compile this simple program: has_iconv.cpp #include <iconv.h> int main() { iconv_t d = iconv_open(0,0); (void)(d); } With g++ has_iconv.cpp -liconv Also BBv2 script of Boost.Locale finds the iconv without a problem, so I'm quite lost. So if anybody that uses Boost from svn-trunk can check why has_iconv test fails (if it is on their machines) and see if ./bjam libs/locale/test prints ....... - iconv (libc) : no - iconv (separate) : no ....... And for what reason (if the sample code above compiles) I would be grateful. Because I have no idea what happens there and I don't have Mac only Darwin 8 which handles it properly. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
On 18 July 2011 13:12, Artyom Beilis <artyomtnk@yahoo.com> wrote:
And for what reason (if the sample code above compiles)
I would be grateful.
It works okay on my Mac (although I'm still running OS X 10.5, not 10.6). But one possibility is that it's using the headers from one location, and the library from another. See this blog post for a description: http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-compiling... found via http://stackoverflow.com/questions/3688700/ The test gcc 4.4 is built using macports, so it's likely they'll have at least two versions of iconv on their machine (the apple one with prefix /usr and the macports one with prefix /opt/local). But that isn't a problem for me, so it might not be the problem here.
----- Original Message ----
From: Daniel James <dnljms@gmail.com> To: boost@lists.boost.org Sent: Tue, July 19, 2011 1:41:23 PM Subject: Re: [boost] [Locale] On Mac OS X 10.6 fails to find iconv
On 18 July 2011 13:12, Artyom Beilis <artyomtnk@yahoo.com> wrote:
And for what reason (if the sample code above compiles)
I would be grateful.
It works okay on my Mac (although I'm still running OS X 10.5, not 10.6). But one possibility is that it's using the headers from one location, and the library from another. See this blog post for a description:
http://blog.yimingliu.com/2009/02/24/missing-library-symbols-while-compiling... / found via http://stackoverflow.com/questions/3688700/
The test gcc 4.4 is built using macports, so it's likely they'll have at least two versions of iconv on their machine (the apple one with prefix /usr and the macports one with prefix /opt/local). But that isn't a problem for me, so it might not be the problem here.
I see. I myself also had seen many complains about iconv and Mac OS X. Hopefully I'll get some logs from the testing machines so it would be possible to specify the correct iconv via ICONV_PATH. Thanks Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
on Tue Jul 19 2011, Artyom Beilis <artyomtnk-AT-yahoo.com> wrote:
Daniel James <dnljms@gmail.com> wrote:
The test gcc 4.4 is built using macports, so it's likely they'll have at least two versions of iconv on their machine (the apple one with prefix /usr and the macports one with prefix /opt/local). But that isn't a problem for me, so it might not be the problem here.
I see. I myself also had seen many complains about iconv and Mac OS X.
Hopefully I'll get some logs from the testing machines so it would be possible to specify the correct iconv via ICONV_PATH.
Thanks
The last, best, hint I heard about how to solve this involved making the built-in iconv.h header inaccessible to the build, so the macports one could more readily be found. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
----- Original Message -----
From: Dave Abrahams <dave@boostpro.com>
I see. I myself also had seen many complains about iconv and Mac OS X.
Hopefully I'll get some logs from the testing machines so it would be possible to specify the correct iconv via ICONV_PATH.
Thanks
The last, best, hint I heard about how to solve this involved making the built-in iconv.h header inaccessible to the build, so the macports one could more readily be found.
There is an explicit notice in "how to build" http://svn.boost.org/svn/boost/trunk/libs/locale/doc/html/building_boost_loc... The problem that on Mac OS X there are frequently two versions of the iconv library - one GNU iconv that have symbols like libiconv_open and iconv_open(x,y) is define for libiconv_open(x,y) and starting form Mac OS X 10.5 or 10.6 there is a system iconv library that comes with iconv_open that defines symbols with same names. So it frequently happens (not for Boost only but also for CMake and any other build system) that iconv.h and libiconv.dylib that are found belong to different libraries. Bottom line, there is no magic way to solve it just user should: 1. Either cleanup his installations (remove gnu iconv or system iconv) 2. Provide an iconv version explicitly. Custom header would not help as the problem is usually on linking stage not compilation. Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/
on Tue Jul 19 2011, Artyom Beilis <artyomtnk-AT-yahoo.com> wrote:
From: Daniel James <dnljms@gmail.com>
The test gcc 4.4 is built using macports, so it's likely they'll have at least two versions of iconv on their machine (the apple one with prefix /usr and the macports one with prefix /opt/local). But that isn't a problem for me, so it might not be the problem here.
I see. I myself also had seen many complains about iconv and Mac OS X.
Hopefully I'll get some logs from the testing machines so it would be possible to specify the correct iconv via ICONV_PATH.
The last, best, hint I heard about how to solve this involved making the built-in iconv.h header inaccessible to the build, so the macports one could more readily be found. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
Artyom Beilis -
Daniel James -
Dave Abrahams