SDK should not include libnacl.so

[GoogleCodeExporter]

The SDK should not include libnacl,so, only libnacl.a. We need applications to 
use libnacl.a and never use libnacl.so. If the SDK includes both, it will use 
libnacl.so by default.

Original issue reported on code.google.com by bradc...@google.com on 21 Oct 2011 at 5:29

[GoogleCodeExporter]

adding Roland.
Once Roland lands a related change, we'll want to know from the SDK team if 
they can produce updates for pepper_15 and pepper_16 SDKs. I'm assuming that 
since these libraries don't have the hex signature in their names, they don't 
need to be matched with a glibc from the same build.

Original comment by bradc...@google.com on 21 Oct 2011 at 6:28

[GoogleCodeExporter]

native_client r7004 should fix the build of libnacl_dyncode.so

Original comment by mcgra...@chromium.org on 21 Oct 2011 at 6:53

[GoogleCodeExporter]

pepper_15 is pretty much out the door, changing that at this point will be very 
painful.

pepper_16 is about to branch, so getting these changes into M16 would be ideal.

Original comment by naclro...@gonacl.com on 21 Oct 2011 at 7:43

[GoogleCodeExporter]

See http://codereview.chromium.org/8371004/
This should eliminate the dependency from libnacl_dyncode.so such that 
libnacl.so can be removed.

Original comment by bradc...@google.com on 21 Oct 2011 at 8:04

[GoogleCodeExporter]

Note that the building of libnacl.so is currently driven by the SDK running 
this command:

scons install --mode=opt-host,nacl libdir=%s includedir=%s platform=x86-%s 
force_sel_ldr=none naclsdk_mode=custom:%s --glibc

(with the %s parameters pointing to the SDK's toolchain.  See SDK 
src/build_tools/make_nacl_tools.py)

If the native_client repository excludes libnacl.so, then excluding it from the 
SDK should just be a matter of rolling the native_client revision in the SDK 
DEPS file.

If this approach is not possible, then we'll have to hack this into the SDK.

Can we skip pepper_16 and just put this into pepper_17 when the appropriate 
native_client changes are complete?  That would be easiest.

Original comment by mball@google.com on 3 Nov 2011 at 7:04

[GoogleCodeExporter]

Roland, can you comment on Matt's question? Including libnacl.so was a problem 
for building libmono.so but if it won't impact builds of other DSOs then 
perhaps it's okay.

I think it might be the case that including libnacl.so would mean that 
pepper_16 could not be used reliably for DSO projects; they would have to use 
pepper_17. 

Original comment by bradc...@google.com on 3 Nov 2011 at 7:50

[GoogleCodeExporter]

The plan is to change the NaCl scons builders so they only make a static 
version of libnacl.a.  When the SDK runs these scons builders, libnacl.so will 
automatically disappear from the bundles.

CL: http://codereview.chromium.org/8499026/

Original comment by dsprin...@chromium.org on 8 Nov 2011 at 7:08

• Changed state: Started

[GoogleCodeExporter]

CL committed to NaCl tree as r7125.  Next step is to roll DEPS in the SDK to 
pull in this rev, and this bug should be fixed.

Original comment by dsprin...@chromium.org on 8 Nov 2011 at 9:32

[GoogleCodeExporter]

Original comment by dsprin...@chromium.org on 28 Nov 2011 at 6:52

• Changed state: Fixed