logging-log4cxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chakravarthula, Krishnamurthy" <krishnamurthy.chakravarth...@siemens.com>
Subject RE: Urgent: log4cxx 0.10.0 build on HP Unix build problem
Date Sat, 03 May 2008 11:04:53 GMT
Hi Arnold,

 I am getting following error when I do make of log4cxx. The earlier
problems got resolved. They were because of my library path settings.
Please advice.

libtool: link: warning: this platform does not like uninstalled shared
libraries
libtool: link: `trivial' will be relinked during installation
g++ -g -O2 -o .libs/trivial trivial.o  -L/u/chakrava/apr
-L/u/chakrava/apr-util
-lm ../../../src/main/cpp/.libs/liblog4cxx.sl
/u/chakrava/apr-util/.libs/libapru
til-1.sl /u/chakrava/apr-util/xml/expat/lib/.libs/libexpat.sl
/u/chakrava/apr/.l
ibs/libapr-1.sl -lrt -lpthread /opt/hp-gcc64-4.2.1/lib/libstdc++.sl
-L/tmp/gcc-4
.2.1.tar.gz/obj/hppa64-hp-hpux11.11/libstdc++-v3/src
-L/tmp/gcc-4.2.1.tar.gz/obj
/hppa64-hp-hpux11.11/libstdc++-v3/src/.libs
-L/tmp/gcc-4.2.1.tar.gz/obj/./gcc -L
/opt/hp-gcc64-4.2.1/hppa64-hp-hpux11.11/bin -L/opt/hp-gcc64-4.2.1/lib
-Wl,+b -Wl
,/u/chakrava/log4cxx/src/main/cpp/.libs:/u/chakrava/apr-util/.libs:/u/ch
akrava/a
pr-util/xml/expat/lib/.libs:/u/chakrava/apr/.libs:/opt/hp-gcc64-4.2.1/li
b:/usr/l
ocal/lib:/usr/local/apr/lib
ld: Can't find dependent library "libaprutil-1.sl.2"
Fatal error.
collect2: ld returned 1 exit status
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
  
Regards,
Krishna

-----Original Message-----
From: Curt Arnold [mailto:carnold@apache.org] 
Sent: Friday, April 25, 2008 6:27 PM
To: Log4CXX User
Subject: Re: Urgent: log4cxx 0.10.0 build on HP Unix build problem


On Apr 25, 2008, at 6:49 AM, Chakravarthula, Krishnamurthy wrote:

> I get the following error when I build log4cxx 0.10.0. Please advice.
> Did anybody get this working on HP Unix. If so, can you please pass on
> the configurations and build steps.
>
> objectptr.cpp: In static member function 'static void*
> log4cxx::helpers::ObjectPtrBase::exchange(void**, void*)':
> objectptr.cpp:41: error: cast from 'void*' to 'apr_uint32_t' loses
> precisiongmake[3]: *** [objectptr.lo] Error 1
> gmake[3]: Leaving directory
> `/u/zztstkqa/jen/apache-log4cxx-0.10.0/src/main/cpp'
> gmake[2]: *** [all-recursive] Error 1
> gmake[2]: Leaving directory
> `/u/zztstkqa/jen/apache-log4cxx-0.10.0/src/main'
> gmake[1]: *** [all-recursive] Error 1
> gmake[1]: Leaving directory `/u/zztstkqa/jen/apache-log4cxx-0.10.0/ 
> src'
> gmake: *** [all-recursive] Error 1
>
>

Glad you got past the APR build problems.

The code that is failing to compile is this little chunk which is  
called by the ObjectPtrT<T> template during assignment operations to  
exchange the new and old values.  It is preferable, but not absolutely  
essential, that this exchange be atomic, so #if's are used to check  
for the presence of atomic exchange methods.

The problem is that the middle chunk in the following code fragment is  
active, but doesn't compile.  If the APR configuration has detected  
that void* is 4 bytes in size, then apr_atomic_xchg32 is used.  The  
compilation error indicates that void* can't be cast to apr_uint32_t  
which is a 32-bit unsigned integer which you'd expect would be able to  
hold a void* if void* was 4 bytes in size.


void* ObjectPtrBase::exchange(void** destination, void* newValue) {
#if _WIN32 && (!defined(_MSC_VER) || _MSC_VER >= 1300)
     return InterlockedExchangePointer(destination, newValue);
#elif APR_SIZEOF_VOIDP == 4
    return (void*) apr_atomic_xchg32((volatile apr_uint32_t*)  
destination,
                           (apr_uint32_t) newValue);
#else
    void* oldValue = *destination;
    *destination = newValue;
    return oldValue;
#endif

You could work around the compile problem, by modifying the #elif so  
that the last fragment is active.  Either a hack

#elif 0

or a refinement of the condition (which please submit back to the list)

#elif APR_SIZEOF_VOIDP == 4 && !defined(SOMEFLAG)

However, the compile error is problematic since it suggests that APR  
might have falsely detected a 32-bit void* when void* is 64-bit or APR  
was compiled as a 32-bit app and log4cxx is being built as a 64-bit  
app.  In either case, bad things would be likely.

If you thought that you were building a 64-bit APR and  
APR_SIZEOF_VOIDP == 4, then something is wrong in APR's configure on  
your platform and you should raise the issue on the user@apr mailing  
list.


Mime
View raw message