Native C, dynamically linked and shared library "Hello World" run.

[motz]

I managed to run two types of native C "Hello world!" on Android.

1) Dynamically linked executable.
This is an executable dynamically linked with system libc.so

2) Dynamically linked executable linked with user's shared library.
This is an executable dynamically linked not only with system
libc.so
but also with the shared library user made.

See below if you are interested.

http://honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-for.html
http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-android.html

motz

[Davanum Srinivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

motz,

Nice! can you please post the binaries of the linker and the strace as well?

thanks,
dims

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFHWwkbgNg6eWEDv1kRApVMAJ9dBE10At/MpSET6q1jzPk5cou1HwCg5Ed9
NHEtbUSxZKVaYAmhYIWWDOY=
=MM9i
-----END PGP SIGNATURE-----

[dasGrunge]

On Dec 8, 3:20 pm, motz <motoya.kuro...@gmail.com> wrote:
> I managed to run two types of native C "Hello world!" on Android.
>
> 1) Dynamically linked executable.
> This is an executable dynamically linked with system libc.so
>
> 2) Dynamically linked executable linked with user's shared library.
> This is an executable dynamically linked not only with system
> libc.so
> but also with the shared library user made.
>
> See below if you are interested.
>

> http://honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-f...http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-a...
>
> motz

Very cool. The --dynamic-linker was the missing link. Thanks, motz!

BTW, just a warning, this only works for C functions and data
structures that are the same between the libc supplied with the
CodeSourcery toolchain and the Android libc. If you stray too far from
the standard, you're bound to blow up.

das

[samo]

Have you tried loading thier libgles_cm.so and calling GL functions?

On Dec 8, 8:20 pm, motz <motoya.kuro...@gmail.com> wrote:
> I managed to run two types of native C "Hello world!" on Android.
>
> 1) Dynamically linked executable.
> This is an executable dynamically linked with system libc.so
>
> 2) Dynamically linked executable linked with user's shared library.
> This is an executable dynamically linked not only with system
> libc.so
> but also with the shared library user made.
>
> See below if you are interested.
>

> http://honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-f...http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-a...
>
> motz

[motz]

Hi, samo

If you mean /system/lib/libopengles_cm.so, NO.

motz

[dasGrunge]

I would think that this should be possible using the header files from
Khronos. But you still need to set up the context before you can draw.
I have a feeling we would need the JNI interfaces available first. Or
figure out what's driving the display.

das

[samo]

Thanks motz,

I've been having quite a lot if success building native applications
with the standard code sourcery tool chain
and linking with the android libs.

Most of the libc functions exposed by android's libc.so match the code
soucery ones quite well and seem to work.
(I had replace ctype.h and write a few wrappers, but nothing much).

I used your modifiation to the linker script to merge the code and
data sections.

However, i'm having trouble with putenv and setenv. They are both
segfaulting.

I suspect this may be due to the fact that the andoird binaries all
seem to have
"environ" undefined:

nm -D android_sdk_linux_m3-rc22a/system/bin/umount | grep env
U environ
U getenv

Whereas my binaries have a local copy of the symbol embedded from
linking with
androids libc.so:

nm -D new_binary | grep env
0001862c B environ
U getenv
U putenv
U setenv

From the map file from my new binary I can see the environ symbol is
coming from libc.so:

.dynbss 0x0001862c 0x4 platform_libs/linux/android/lib/
libc.so
0x0001862c environ

I guess the linker script still needs work and that the "environ"
referenced by the app is not the
one used by putenv.

On Dec 8, 8:20 pm, motz <motoya.kuro...@gmail.com> wrote:

> I managed to run two types of native C "Hello world!" on Android.
>
> 1) Dynamically linked executable.
> This is an executable dynamically linked with system libc.so
>
> 2) Dynamically linked executable linked with user's shared library.
> This is an executable dynamically linked not only with system
> libc.so
> but also with the shared library user made.
>
> See below if you are interested.
>

> http://honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-f...http://honeypod.blogspot.com/2007/12/shared-library-hello-world-for-a...
>
> motz

[motz]

Hi, samo,

Initialization of libc is needed.

I wrote the article about it. Please see below.

http://honeypod.blogspot.com/2007/12/initialize-libc-for-android.html

motz

> >http://honeypod.blogspot.com/2007/12/dynamically-linked-hello-world-f......
>
> > motz

[Davanum Srinivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey Motz,

The #include's don't show up well in the blog post :)

#include <stdio.h>
#include <unistd.h>

- -- dims

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)

iD8DBQFHYTmGgNg6eWEDv1kRAuVGAKDHAZ27pKMNkmgoARXD5Cjo+MLdAACgkaHF
/QHmpVpuoKRv2IlOSec4W7U=
=RJE/
-----END PGP SIGNATURE-----

[motz]

Hi, dims,

Fixed!

Thanks

motz

[Davanum Srinivas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Great work BTW!!! Keep 'em coming :)

- -- dims

motz wrote:
> Hi, dims,
>
> Fixed!
>
> Thanks
>
> motz
>
> On 12月13日, 午後10:54, Davanum Srinivas <dava...@gmail.com> wrote:
> Hey Motz,
>
> The #include's don't show up well in the blog post :)
>
> #include <stdio.h>
> #include <unistd.h>
>

> -- dims
>
>
>
> motz wrote:
>>>> Hi, samo,
>>>> Initialization of libc is needed.
>>>> I wrote the article about it. Please see below.
>>>> http://honeypod.blogspot.com/2007/12/initialize-libc-for-android.html
>>>> motz

iD8DBQFHYTwYgNg6eWEDv1kRAhgPAKC8zI0BofRpOuJnNnHL/WWHyfW96QCgsYai
qBZQPQz4u5y77BtRHalXL6g=
=ycpW
-----END PGP SIGNATURE-----