search

rooneypark / naclports

Automatically exported from code.google.com/p/naclports
0 stars 0 forks source link

zlib-1.2.3 fails to build under glibc on OSX #77

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. compilation: ># NACL_GLIBC=1 NACL_ARCH=x86_64 make
2. zlib-1.2.3 fail to build because it is not building so.1

What is the expected output? What do you see instead?

Expected:
$USER/Devel/nacl_sdk/pepper_canary/tools/ncval libz.so.1

Failing:
./configure 
--prefix=$USER/Devel/nacl_sdk/pepper_canary/toolchain/mac_x86_glibc/x86_64-nacl/
usr --shared
Checking for shared library support...
No shared library support; try without defining CC and CFLAGS
.
.
.
$USER/Devel/nacl_sdk/pepper_canary/tools/ncval libz.so.1
Failed to open input file: libz.so.1

What version of the product are you using? On what operating system?

tried: pepper_28, 29 and canary, OsX10.8.3 x86_64

Please provide any additional information below.

Previous version of the build script was different:

https://code.google.com/p/naclports/source/diff?spec=svn835&r=739&format=side&pa
th=/trunk/src/libraries/zlib/nacl-zlib.sh&old_path=/trunk/src/libraries/zlib/nac
l-zlib.sh&old=682

Original issue reported on code.google.com by dadri...@gmail.com on 14 Aug 2013 at 1:59

GoogleCodeExporter commented 9 years ago 
Sounds like this might be an OSX related issue as it builds fine on linux.

Can you attach the config.log file which might tell use why it thinks shared 
libraries are not supported.

Original comment by sbc@google.com on 14 Aug 2013 at 3:10

GoogleCodeExporter commented 9 years ago

Original comment by sbc@google.com on 14 Aug 2013 at 3:10

GoogleCodeExporter commented 9 years ago 
Hi, 

Yes, you are right. I checked the configure script (zlib-1.2.3/configure) and 
it seems to need a patch:

The problem is in the case sentence at line 78, in my system it will 
"correctly" choose the Darwin style LDSHARED, which is incompatible with 
nacl_gcc, what we need here is linux style LDSHARED (tested):

 78   case `(uname -s || echo unknown) 2>/dev/null` in
 79   Linux | linux | GNU | GNU/*) LDSHARED=${LDSHARED-"$cc -shared -Wl,-soname,libz.so.1"};;
 80   CYGWIN* | Cygwin* | cygwin* | OS/2* )
 81              EXE='.exe';;
 82   QNX*)  # This is for QNX6. I suppose that the QNX rule below is for QNX2,QNX4
 83          # (alain.bonnefoy@icbt.com)
 84                  LDSHARED=${LDSHARED-"$cc -shared -Wl,-hlibz.so.1"};;
 85   HP-UX*)
 86          LDSHARED=${LDSHARED-"$cc -shared $SFLAGS"}
 87          case `(uname -m || echo unknown) 2>/dev/null` in
 88          ia64)
 89                  shared_ext='.so'
 90                  SHAREDLIB='libz.so';;
 91          *)
 92                  shared_ext='.sl'
 93                  SHAREDLIB='libz.sl';;
 94          esac;;
 95   Darwin*)   #shared_ext='.dylib'
 96              SHAREDLIB=libz$shared_ext
 97              SHAREDLIBV=libz.$VER$shared_ext
 98              SHAREDLIBM=libz.$VER1$shared_ext
 99              LDSHARED=${LDSHARED-"$cc -dynamiclib -install_name $libdir/$SHAREDLIBM -compatibility_version $VER1 -current_version $VER"};;
100   *)             LDSHARED=${LDSHARED-"$cc -shared"};;
101   esac

Original comment by dadri...@gmail.com on 14 Aug 2013 at 10:23

GoogleCodeExporter commented 9 years ago 
Ah.  Makes sense.   Perhaps we can find some way to override this so that it 
doesn't look at uname at all, and in the worst case we can just patch configure.

Thanks for you help investigating.

Original comment by sbc@chromium.org on 14 Aug 2013 at 11:32

GoogleCodeExporter commented 9 years ago

Original comment by sbc@google.com on 19 Jun 2014 at 6:12

GoogleCodeExporter commented 9 years ago 
This was fixed at r1088

Original comment by sbc@google.com on 30 Sep 2014 at 11:17

GoogleCodeExporter commented 9 years ago

Original comment by sbc@google.com on 30 Sep 2014 at 11:17