One thing of note is currently LTO doesn't work on clang with the NDK.

Looks like when we went through the same exercise as Ivan it was not using
cmake but the raw makefile and I have this change:
-            -Wl,-soname=$(LIBOBJCXX).so.$(MAJOR_VERSION) $(LDFLAGS) \
+            -Wl,-soname=$(LIBOBJCXX).so $(LDFLAGS) -ldispatch \
in git.  Not the best change but we were trying a lot of different things.


Having a repeatable easy to build libobjc2/gnustepbase/corebase on Android
would be a big win.



On Mon, Dec 30, 2013 at 3:50 AM, David Chisnall <thera...@sucs.org> wrote:

>
> On 30 Dec 2013, at 10:58, Ivan Vučica <ivuc...@gmail.com> wrote:
>
> > Still, if one wants to build separate libobjc, could you look into
> forcing soname to be just "libobjc.so", solely for the Android platform? If
> I understand the CMake way of thinking, that should be done in the
> toolchain specification file, right?
>
> The version extension is set by the SOVERSION target property, which is
> used to define the extension.  If you can give me a way of detecting that
> Android is the target, then it's easy to either not set this, or explicitly
> set the NO_SONAME target property to true (which has the same effect).
>
> > Even before I read the entire mail the first thought that came to me was
> the legal issues with LGPL. :-)
> >
> > And single libgnustep.so does sound like a good approach for any
> proprietary apps.
> >
> > We could support 3 scenarios:
> > - fully statically linked with app (with a big label about advantages
> plus about legal requirements)
> > - statically linked up to libgnustep.so
> > - every library for itself
>
> I'm not sure that there's any advantage in the last one, to be honest.
>  With the statically linked libgnustep.so, we get the possibility of doing
> LTO (which should reduce binary sizes, which is probably a good thing for
> Android!) and of doing more of the relocations statically so that we will
> get faster startup times.
>
> David
>
> -- Sent from my Apple II
>
>
> _______________________________________________
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to