Cannot build glog as universal binary on Mac OS X (snow leopard)

[GoogleCodeExporter]

With a configuration for a universal binary : 

./configure -q --disable-dependency-tracking --enable-static
--enable-shared --prefix=/tmp/glog  --with-threads  'LDFLAGS=-isysroot
/Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -arch ppc ' 
'CFLAGS= -g0 -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch
x86_64 -arch ppc ' 'CXXFLAGS= -g0 -isysroot /Developer/SDKs/MacOSX10.6.sdk
-arch i386 -arch x86_64 -arch ppc '

make fails:
...
g++ -DHAVE_CONFIG_H -I. -I./src -I./src -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -DNDEBUG -g0 -isysroot
/Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64 -arch ppc -c
src/raw_logging.cc -o libglog_la-raw_logging.o >/dev/null 2>&1
src/logging.cc: In function ‘int google::posix_strerror_r(int, char*, 
size_t)’:
src/logging.cc:1758: error: cast from ‘char*’ to ‘int’ loses precision
...

guilty line of code : 
      buf[0] = '\000';
#if defined(OS_MACOSX) || defined(OS_FREEBSD) || defined(OS_OPENBSD)
>>>>>>>>      if (reinterpret_cast<int>(rc) < sys_nerr) { <<<<<<<<<
        // This means an error on MacOSX or FreeBSD.
        return -1;
      }
#endif
      strncat(buf, rc, len-1);

I suspect that the problem emerges on a 64bit build for Mac OS X, modifying
the 'reinterpret_cast<int>(rc)' to 'reinterpret_cast<long int>(rc)' fixes
the build, but i don't think it's a correct way to solve that.

Original issue reported on code.google.com by nicolas....@gmail.com on 18 Sep 2009 at 6:58

[GoogleCodeExporter]

This change would fix this issue.

http://code.google.com/p/google-glog/source/detail?r=72

There seem to be still errors around ucontext and stacktracing in Snow Leopard. 
I'll 
look into them... Maybe we can re-use perftools' results.

http://code.google.com/p/google-perftools/issues/detail?id=169

Original comment by shinichi...@gmail.com on 7 Oct 2009 at 8:54

[GoogleCodeExporter]

FYI, I just tried to build this on Snow Leper with just that change.

It all compiles and links... but then I get the error below when I "make 
check", 
indicating (accurately) that .libs/libglog.so doesn't exist (I also attached a 
directory 
listing of .libs).

Sorry, don't have time to follow this up further today but wanted at least to 
make a 
clear trouble report...

make  logging_striplog_test_sh demangle_unittest_sh signalhandler_unittest_sh
./src/logging_striplog_test.sh
./src/logging_striplog_test.sh: line 69: 62744 Abort trap              
./logging_striptest2 
2> /dev/null
PASS
./demangle_unittest  # force to create lt-demangle_unittest
Passed 2 tests

PASS
./src/demangle_unittest.sh
nm: can't open file: .libs/libglog.so (No such file or directory)
PASS
./signalhandler_unittest  # force to create lt-signalhandler_unittest
OK
./src/signalhandler_unittest.sh
./src/signalhandler_unittest.sh: line 76: 62830 Segmentation fault      
GOOGLE_LOG_DIR=. $BINARY segv 2> signa\
lhandler.out1
'main' should appear in the output
make[1]: *** [signalhandler_unittest_sh] Error 1
make: *** [check-am] Error 2

  -rwxr-xr-x   1 tom  tom    30288 Mar 25 17:03 demangle_unittest
  -rwxr-xr-x   1 tom  tom   156824 Mar 25 17:03 libglog.0.0.0.dylib
  drwxr-xr-x   3 tom  tom      102 Mar 25 17:03 libglog.0.0.0.dylib.dSYM
  lrwxr-xr-x   1 tom  tom       19 Mar 25 17:03 libglog.0.dylib -> libglog.0.0.0.dylib
  -rw-r--r--   1 tom  tom  1035016 Mar 25 17:03 libglog.a
  lrwxr-xr-x   1 tom  tom       19 Mar 25 17:03 libglog.dylib -> libglog.0.0.0.dylib
  lrwxr-xr-x   1 tom  tom       13 Mar 25 17:03 libglog.la -> ../libglog.la
  -rw-r--r--   1 tom  tom      837 Mar 25 17:03 libglog.lai
  -rw-r--r--   1 tom  tom    53440 Mar 25 17:03 libglog_la-demangle.o
  -rw-r--r--   1 tom  tom   516360 Mar 25 17:03 libglog_la-logging.o
  -rw-r--r--   1 tom  tom    78692 Mar 25 17:03 libglog_la-raw_logging.o
  -rw-r--r--   1 tom  tom    99712 Mar 25 17:03 libglog_la-signalhandler.o
  -rw-r--r--   1 tom  tom    76144 Mar 25 17:03 libglog_la-symbolize.o
  -rw-r--r--   1 tom  tom   100368 Mar 25 17:03 libglog_la-utilities.o
  -rw-r--r--   1 tom  tom    98880 Mar 25 17:03 libglog_la-vlog_is_on.o
  -rwxr-xr-x   1 tom  tom    10904 Mar 25 17:03 logging_striptest0
  -rwxr-xr-x   1 tom  tom    22896 Mar 25 17:03 logging_striptest10
  -rwxr-xr-x   1 tom  tom    20648 Mar 25 17:03 logging_striptest2
  -rwxr-xr-x   1 tom  tom   156752 Mar 25 17:03 logging_unittest
  -rwxr-xr-x   1 tom  tom    11072 Mar 25 17:03 signalhandler_unittest
  -rwxr-xr-x   1 tom  tom    16976 Mar 25 17:03 stacktrace_unittest
  -rwxr-xr-x   1 tom  tom    74128 Mar 25 17:03 stl_logging_unittest
  -rwxr-xr-x   1 tom  tom    19024 Mar 25 17:03 symbolize_unittest
  -rwxr-xr-x   1 tom  tom    23320 Mar 25 17:03 utilities_unittest

Original comment by tom.ritc...@gmail.com on 25 Mar 2010 at 9:11

[GoogleCodeExporter]

Hi guys, long time no see!

I solved this problem by casting the right side to void*, but yeah, this needs 
to be fixed.

Original comment by vij...@gmail.com on 25 Mar 2010 at 9:15

[GoogleCodeExporter]

Hey, Vijay!  Long time, etc!  How goes it?

That does make it compile (though I don't think it'll work if error codes are 
ever 
negative, right, because they'll end up appearing to be large and positive?)

However, I still get that same linker error.

Not a big priority, I ran into this library and just wanted to see if it worked 
on my 
machine here...

Original comment by tom.ritc...@gmail.com on 25 Mar 2010 at 9:32

[GoogleCodeExporter]

This appears to be fixed in 0.3.1!

Original comment by tom.ritc...@gmail.com on 4 Aug 2010 at 7:38