Compiling log4cxx on OS X 10.3.9

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling log4cxx on OS X 10.3.9

Juri Ganitkevitch
Hello everyone,

I'm having some problems compiling log4cxx on my iBook. This goes for the 0.9.7 release as well as for the
current CVS HEAD.

Leaving the 0.9.7 as it is gets me a libtool error (while make-ing):

/bin/sh ../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../include/log4cxx -I../include -I/usr/
include/libxml2  -D_REENTRANT  -g -O2 -c -o appenderattachableimpl.lo `test -f
'appenderattachableimpl.cpp' || echo './'`appenderattachableimpl.cpp
libtool: ltconfig version `' does not match ltmain.sh version `1.3.5'
Fatal configuration error.  See the libtool docs for more information.

Trying to ant the CVS HEAD leaves me with a linker error:

[cc] Starting link
[cc] ld: /Users/jg/Downloads/Compile/logging-log4cxx/build/debug/static/libaprutil-1.a(xlate.o) illegal
      reference to symbol: _libiconv defined in indirectly referenced dynamic library /usr/lib/libiconv.2.dylib
[cc] /usr/bin/libtool: internal link edit command failed

As you see, I'm not very knowing in terms of libtool, linking etc. Anybody here, who got log4cxx running on a
Mac? I just seem to be to dumb to get it to compile.

Could this be caused by Apple's std. libtool? Or any potential libtool version garbage I created (I think I created
some..)?

Thanks a big lot, I'm really starting to get desperate.

Greetings,

Juri

Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

carnold-3

On May 13, 2005, at 10:14 AM, Juri Ganitkevitch wrote:


> Trying to ant the CVS HEAD leaves me with a linker error:
>
> [cc] Starting link
> [cc] ld: /Users/jg/Downloads/Compile/logging-log4cxx/build/debug/
> static/libaprutil-1.a(xlate.o) illegal
>       reference to symbol: _libiconv defined in indirectly  
> referenced dynamic library /usr/lib/libiconv.2.dylib
> [cc] /usr/bin/libtool: internal link edit command failed
>
>


Using the CVS HEAD is better, you aren't on your own.  Looks like I  
forgot to put in code to detect the need to link iconv.  Try adding a  
-Dhas-iconv=true to the Ant command line as a workaround.

Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

Juri Ganitkevitch
In reply to this post by Juri Ganitkevitch
First off, thanks a lot!

This resolves the libiconv error (actually I should have found this myself, I saw after looking at the first 10 lines
of build.xml, sorry).

The change you pointed out leads to another linker error, this time related to log4cxx itself:

       [cc] ld: Undefined symbols:
       [cc] log4cxx::helpers::UnicodeHelper::decodeWide(wchar_t const*&, wchar_t const*)
       [cc] log4cxx::helpers::UnicodeHelper::encodeWide(unsigned int, wchar_t*)
       [cc] /usr/bin/libtool: internal link edit command failed

This is not related to the

#if LOG4CXX_HAS_WCHAR_T

around them (tried without, same result).

Do you have any suggestions??

Again, thank you for the fast and helpful reply!!

Greetings,

Juri


Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

Curt Arnold-2
I haven't rebuild on Mac since I did those and just started doing  
some quick reading.  Having those symbols undefined is an intentional  
indication that the code could not recognize the wchar_t as one of  
the two currently supported mappings, UTF-16LE (for Windows, detected  
when _WIN32 is defined) and UCS-4 (when __STD_ISO_10646... is  
defined).  I haven't figured out exactly what wchar_t is on the Mac  
platform (it suggests CFString to be used in place of wstring).  
Until I can cycle over to the Mac (I do a slow iteration among  
platforms), I would suggest that you build log4cxx with use of  
wchar_t disabled.

ant -Dhas.wchar_t=0




On May 13, 2005, at 10:51 AM, Juri Ganitkevitch wrote:

> First off, thanks a lot!
>
> This resolves the libiconv error (actually I should have found this  
> myself, I saw after looking at the first 10 lines
> of build.xml, sorry).
>
> The change you pointed out leads to another linker error, this time  
> related to log4cxx itself:
>
>        [cc] ld: Undefined symbols:
>        [cc] log4cxx::helpers::UnicodeHelper::decodeWide(wchar_t  
> const*&, wchar_t const*)
>        [cc] log4cxx::helpers::UnicodeHelper::encodeWide(unsigned  
> int, wchar_t*)
>        [cc] /usr/bin/libtool: internal link edit command failed
>
> This is not related to the
>
> #if LOG4CXX_HAS_WCHAR_T
>
> around them (tried without, same result).
>
> Do you have any suggestions??
>
> Again, thank you for the fast and helpful reply!!
>
> Greetings,
>
> Juri
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

carnold-3
I've changed the build.xml file to assume that iconv is present on  
the Mac and to fail with a hopefully informative message if -
Dhas.wchar_t=0 is not set.

That got the log4cxx to build and run the trivial sample problem, but  
cppunit would fail to link as a shared library (missing typeinfo  
symbols).  The trivial example would compile and run.

I've opened bug http://issues.apache.org/jira/browse/LOGCXX-85 for  
any Mac OS/X specific wishes.  The ones I can come up with were to  
use CFString as LogString (the internal string type), to add  
CFString overloads where there are currently std::wstring and  
std::string overloads (for example, Logger.info()) and to have  
OutputDebugStringAppender output to NSLog.  If you have any more,  
please add them to that bug.  I'll will try to get back in a few days.
Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

Juri Ganitkevitch
Thanks a great lot!!!

As I'm working to port a project using log4cxx, I expect to be able to
provide some feedback here. With time to come, I hope to be of more
practical help.

Greetings,

Juri

On 14. May, 2005, at 05:01, Curt Arnold wrote:

> I've changed the build.xml file to assume that iconv is present on the
> Mac and to fail with a hopefully informative message if
> -Dhas.wchar_t=0 is not set.
>
> That got the log4cxx to build and run the trivial sample problem, but
> cppunit would fail to link as a shared library (missing typeinfo
> symbols).  The trivial example would compile and run.
>
> I've opened bug http://issues.apache.org/jira/browse/LOGCXX-85 for any
> Mac OS/X specific wishes.  The ones I can come up with were to use
> CFString as LogString (the internal string type), to add  CFString
> overloads where there are currently std::wstring and std::string
> overloads (for example, Logger.info()) and to have
> OutputDebugStringAppender output to NSLog.  If you have any more,
> please add them to that bug.  I'll will try to get back in a few days.
>


Reply | Threaded
Open this post in threaded view
|

Re: Compiling log4cxx on OS X 10.3.9

Juri Ganitkevitch
In reply to this post by carnold-3
Thanks a great lot!!!

As I'm working to port a project using log4cxx, I expect to be able to
provide some feedback here. With time to come, I hope to be of more
practical help.

Greetings,

Juri

On 14. May, 2005, at 05:01, Curt Arnold wrote:

> I've changed the build.xml file to assume that iconv is present on the
> Mac and to fail with a hopefully informative message if
> -Dhas.wchar_t=0 is not set.
>
> That got the log4cxx to build and run the trivial sample problem, but
> cppunit would fail to link as a shared library (missing typeinfo
> symbols).  The trivial example would compile and run.
>
> I've opened bug http://issues.apache.org/jira/browse/LOGCXX-85 for any
> Mac OS/X specific wishes.  The ones I can come up with were to use
> CFString as LogString (the internal string type), to add  CFString
> overloads where there are currently std::wstring and std::string
> overloads (for example, Logger.info()) and to have
> OutputDebugStringAppender output to NSLog.  If you have any more,
> please add them to that bug.  I'll will try to get back in a few days.
>