Skip to main content

mr1 cvm shared library problem

9 replies [Last post]
lamsap
Offline
Joined: 2004-11-09
Points: 0

Hi,

I have compiled cvm (foundation profile) for an arm-be (big endian) Intel XScale IXP465 processor. The build tools were from snapgear, and the linux distribution was from the vendor, ADI (Sidewinder board). The kernel compiles file.

When I run cvm:

# ./cvm
./cvm: can't load library 'libdl.so.2'
# add libdl.so.2 into lib
# ./cvm
libc.so.6: aborted attempt to load ./cvm!
# add libc.so.6 into lib
# ./cvm
libc.so.6: aborted attempt to load ./cvm!

libc.so.6 and libdl.so.2 both came from my toolchain (/usr/local/arm-linux/lib/be/)

Here is the results from running file on various files in the system:
# file cvm libc.so.6 libdl.so.2 libdl.so.0 libc.so.0 ../bin/bash ../bin/busybox
cvm: ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped
libc.so.6: ELF 32-bit MSB shared object, ARM, version 1 (ARM), for GNU/Linux 2.0.0, stripped
libdl.so.2: ELF 32-bit MSB shared object, ARM, version 1 (ARM), for GNU/Linux 2.0.0, stripped
libdl.so.0: ELF 32-bit MSB shared object, ARM, version 1 (ARM), stripped
libc.so.0: ELF 32-bit MSB shared object, ARM, version 1 (ARM), stripped
../bin/bash: ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped
../bin/busybox: ELF 32-bit MSB executable, ARM, version 1 (ARM), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped

bash and busybox run fine (they are built with the ADI linux distribution).

Any ideas as to why it is not running?

I would also be open to the idea of trying to compile cvm against uClibc (0.9.27 comes with the ADI distribution), anyone had any experience trying to get these two working together?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
lamsap
Offline
Joined: 2004-11-09
Points: 0

Aha! I can now get it to compile using the ucfront tool provided in the kernel dist for uclibc, and it runs, kinda:

# pwd
/bin
# ./cvm
Invalid path /bin/cvm
Executable must be in a directory named "bin".
Cannot start VM (CVMinitStaticState failed)
Could not create JVM.

However I haven't uploaded the associated jars and stuff, only the cvm binary, so I've still to properly install it.

FYI the changes to my Makefile to make it compile with uclibc 0.9.27 were:

TARGET_CC = /home/dev/project/sidewinder/docs/ADI/tools/ucfront-gcc arm-linux-gcc
TARGET_CCC = /home/dev/project/sidewinder/docs/ADI/tools/ucfront-g++ arm-linux-g++
TARGET_AR = /usr/local/bin/arm-linux-ar
TARGET_RANLIB = /usr/local/bin/arm-linux-ranlib

CONFIG_DEFAULTS_LIBC_UCLIBC=true

Thank you for your help, much appreciated!

Hopefully this'll help anyone else who may encounter this problem...

xyzzy
Offline
Joined: 2006-08-30
Points: 0

Interesting, I had never heard of ucfront before.

It looks like you have discovered a minor bug.
cvm expects to be run from /bin/,
but it gets confused if there are no /'s in
. Try /usr/bin/cvm or similar and
this error should go away.

Dean

> Aha! I can now get it to compile using the ucfront
> tool provided in the kernel dist for uclibc, and it
> runs, kinda:
>
> # pwd
> /bin
> # ./cvm
> Invalid path /bin/cvm
> Executable must be in a directory named "bin".
> Cannot start VM (CVMinitStaticState failed)
> Could not create JVM.
>
> However I haven't uploaded the associated jars and
> stuff, only the cvm binary, so I've still to properly
> install it.
>
> FYI the changes to my Makefile to make it compile
> with uclibc 0.9.27 were:
>
> TARGET_CC =
> /home/dev/project/sidewinder/docs/ADI/tools/ucfront-g
> c arm-linux-gcc
> TARGET_CCC =
> /home/dev/project/sidewinder/docs/ADI/tools/ucfront-g
> + arm-linux-g++
> TARGET_AR = /usr/local/bin/arm-linux-ar
> TARGET_RANLIB = /usr/local/bin/arm-linux-ranlib
>
> CONFIG_DEFAULTS_LIBC_UCLIBC=true
>
> Thank you for your help, much appreciated!
>
> Hopefully this'll help anyone else who may encounter
> this problem...

xyzzy
Offline
Joined: 2006-08-30
Points: 0

> I have:
>
> # ls -l
> -rwxr-xr-x 1 0 0 3136947 cvm
> lrwxrwxrwx 1 0 0 24
> ld-linux.so.2 -> /lib/ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312
> ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312
> ld-uClibc.so.0
> -rw-r--r-- 1 0 0 276268 libc.so.0
> -rw-r--r-- 1 0 0 10688
> libcrypt-0.9.27.so
> -rw-r--r-- 1 0 0 10688
> libcrypt.so.0
> -rw-r--r-- 1 0 0 7160
> libdl-0.9.27.so
> -rw-r--r-- 1 0 0 7160
> libdl.so.0
> -rwxr-xr-x 1 0 0 9496
> libdl.so.2
> -rw-r--r-- 1 0 0 53184
> libm-0.9.27.so
> -rw-r--r-- 1 0 0 53184 libm.so.0
> -rw-r--r-- 1 0 0 1416
> libnsl-0.9.27.so
> -rw-r--r-- 1 0 0 1416
> libnsl.so.0
> -rw-r--r-- 1 0 0 68592
> libpthread-0.9.27.so
> -rw-r--r-- 1 0 0 68592
> libpthread.so.0
> -rw-r--r-- 1 0 0 1420
> libresolv-0.9.27.so
> -rw-r--r-- 1 0 0 1420
> libresolv.so.0
> -rw-r--r-- 1 0 0 1320
> librt-0.9.27.so
> -rw-r--r-- 1 0 0 1320
> librt.so.0
> -rw-r--r-- 1 0 0 276268
> libuClibc-0.9.27.so
> -rw-r--r-- 1 0 0 4120
> libutil-0.9.27.so
> -rw-r--r-- 1 0 0 4120
> libutil.so.0
>
> I can't ldd any files using the toolkit's ldd:
> /usr/local/arm-linux/bin/ldd cvm
> usr/local/arm-linux/bin/ldd: line 132:
> /usr/local/arm-linux/lib/ld-linux.so.2: cannot
> execute binary file
> /usr/local/arm-linux/bin/ldd: line 142:
> /usr/local/arm-linux/lib/ld-linux.so.2: cannot
> execute binary file
> ldd: /usr/local/arm-linux/lib/ld-linux.so.2 exited
> with unknown exit code (126)
>
> I am a bit suspect about libc.so.6 and libdl.so.2
> since I got them from my toolchain
> (/usr/local/arm-linux/lib/be/libc.so.6 etc...), and
> were not generated while building the kernel... but
> the file command seems to think they are of the
> correct type.

"/usr/local/arm-linux/bin/ldd" makes me think you are trying to run ldd on the host. If you can't run ldd on the target, then try "objdump" on the host. Or you can try
setting the environment variable LD_TRACE_LOADED_OBJECTS before running cvm, assuming uClibc supports it.

Dean

lamsap
Offline
Joined: 2004-11-09
Points: 0

Yes I tried ldd on the host, can't try on target.

Looks like all the shared libraries required are present on the target (libdl.so.2, libc.so.6, libpthread.so.0).

Objdump (run from host) provides:

# /usr/local/arm-linux/bin/objdump -x cvm

cvm: file format elf32-bigarm
cvm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x000514a0

Program Header:
PHDR off 0x00000034 vaddr 0x00008034 paddr 0x00008034 align 2**2
filesz 0x000000c0 memsz 0x000000c0 flags r-x
INTERP off 0x000000f4 vaddr 0x000080f4 paddr 0x000080f4 align 2**0
filesz 0x00000013 memsz 0x00000013 flags r--
LOAD off 0x00000000 vaddr 0x00008000 paddr 0x00008000 align 2**15
filesz 0x0023ce78 memsz 0x0023ce78 flags r-x
LOAD off 0x0023d000 vaddr 0x0024d000 paddr 0x0024d000 align 2**15
filesz 0x00000d84 memsz 0x0005b40c flags rw-
DYNAMIC off 0x0023d014 vaddr 0x0024d014 paddr 0x0024d014 align 2**2
filesz 0x000000d8 memsz 0x000000d8 flags rw-
NOTE off 0x00000108 vaddr 0x00008108 paddr 0x00008108 align 2**2
filesz 0x00000020 memsz 0x00000020 flags r--

Dynamic Section:
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libc.so.6
INIT 0x50d98
FINI 0xe72e4
HASH 0x8128
STRTAB 0x24110
SYMTAB 0x10e00
STRSZ 0x2a086
SYMENT 0x10
DEBUG 0x0
PLTGOT 0x24d0ec
PLTRELSZ 0x490
PLTREL 0x11
JMPREL 0x50908
REL 0x508c8
RELSZ 0x40
RELENT 0x8
VERNEED 0x507f8
VERNEEDNUM 0x3
VERSYM 0x4e196

Version References:
required from libdl.so.2:
0x0d696911 0x00 11 GLIBC_2.1
0x0d696910 0x00 06 GLIBC_2.0
required from libc.so.6:
0x0d696913 0x00 10 GLIBC_2.3
0x0d696912 0x00 09 GLIBC_2.2
0x0d696911 0x00 08 GLIBC_2.1
0x0d696910 0x00 03 GLIBC_2.0
required from libpthread.so.0:
0x0d696912 0x00 07 GLIBC_2.2
0x0d696910 0x00 05 GLIBC_2.0
0x0d696911 0x00 04 GLIBC_2.1
0x09691972 0x00 02 GLIBC_2.3.2
private flags = 2: [APCS-32] [FPA float format] [has entry point]

Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 00000013 000080f4 000080f4 000000f4 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .note.ABI-tag 00000020 00008108 00008108 00000108 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_DISCARD
2 .hash 00008cd8 00008128 00008128 00000128 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynsym 00013310 00010e00 00010e00 00008e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .dynstr 0002a086 00024110 00024110 0001c110 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .gnu.version 00002662 0004e196 0004e196 00046196 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 .gnu.version_r 000000d0 000507f8 000507f8 000487f8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 .rel.dyn 00000040 000508c8 000508c8 000488c8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 .rel.plt 00000490 00050908 00050908 00048908 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 .init 0000001c 00050d98 00050d98 00048d98 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .plt 000006ec 00050db4 00050db4 00048db4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
11 .text 00095e44 000514a0 000514a0 000494a0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
12 .fini 00000018 000e72e4 000e72e4 000df2e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
13 .rodata 0015db74 000e7300 000e7300 000df300 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 .eh_frame 00000004 00244e74 00244e74 0023ce74 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 .ctors 00000008 0024d000 0024d000 0023d000 2**2
CONTENTS, ALLOC, LOAD, DATA
16 .dtors 00000008 0024d008 0024d008 0023d008 2**2
CONTENTS, ALLOC, LOAD, DATA
17 .jcr 00000004 0024d010 0024d010 0023d010 2**2
CONTENTS, ALLOC, LOAD, DATA
18 .dynamic 000000d8 0024d014 0024d014 0023d014 2**2
CONTENTS, ALLOC, LOAD, DATA
19 .got 00000268 0024d0ec 0024d0ec 0023d0ec 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .data 00000a30 0024d354 0024d354 0023d354 2**2
CONTENTS, ALLOC, LOAD, DATA
21 .bss 0005a688 0024dd84 0024dd84 0023dd84 2**2
ALLOC
22 .comment 00001128 00000000 00000000 0023dd84 2**0
CONTENTS, READONLY
SYMBOL TABLE:
no symbols

I see when I do an objdump on libc.so.6 and libdl.so.2, they both seem to require ld-linux.so.2, which isn't on the target. Does the below output tend to indicate that they need ld-linux.so.2?

# /usr/local/arm-linux/bin/objdump -x libc.so.6
...

Dynamic Section:
NEEDED ld-linux.so.2
SONAME libc.so.6
INIT 0x16de0
FINI_ARRAY 0x12d000
FINI_ARRAYSZ 0x4
HASH 0x114

... snip ...

Version definitions:
1 0x01 0x0865f4e6 libc.so.6
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
GLIBC_2.0

... snip ...

Version References:
required from ld-linux.so.2:
0x0d696911 0x00 20 GLIBC_2.1
0x0d696910 0x00 19 GLIBC_2.0
0x0963cf85 0x00 18 GLIBC_PRIVATE
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]

I guess the NEEDED line sells it eh? I won't be able to confirm if this the problem til Monday, but *fingers crossed* this solves it! Cheers!

xyzzy
Offline
Joined: 2006-08-30
Points: 0

Now I'm a bit confused, because before you said:

> I have:
>
> # ls -l
> -rwxr-xr-x 1 0 0 3136947 cvm
> lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312 ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312 ld-uClibc.so.0

which seems to be showing that ld-linux.so.2 is on the target,
but now you say it isn't on the target. I think this is the library that provides
dynamic linking, so if it was missing not even "ls" would work, unless
for some odd reason everything is statically linked.

You might want to write a simple test program that calls dlsym(),
then link it with -ldl. If you can get that to run, then there is a good
change cvm will run. If it won't run, then you may need to ask for help
from the toolchain vendor or busybox forum.

Dean

lamsap
Offline
Joined: 2004-11-09
Points: 0

True. I checked again on the target:

# LD_TRACE_LOADED_OBJECTS=1 ./cvm
libpthread.so.0 => /lib/libpthread.so.0 (0x4000e000)
libdl.so.2 => /lib/libdl.so.2 (0x40029000)
libc.so.6 => /lib/libc.so.6 (0x40033000)
libc.so.0 => /lib/libc.so.0 (0x40166000)
ld-linux.so.2 => /lib/ld-linux.so.2 (0x401b4000)
ld-uClibc-0.9.27.so => /lib/ld-uClibc-0.9.27.so (0x40000000)

I wonder that since ld-linux.so.2 -> /lib/ld-uClibc-0.9.27.so, and libc.so.6 requires ld-linux.so.2, so I wonder if that it requires the glibc version of ld-linux.so.2, rather than the uClibc one provided.

I'll try the test program suggestion too, cheers.

xyzzy
Offline
Joined: 2006-08-30
Points: 0

> Hi,
>
> I have compiled cvm (foundation profile) for an
> arm-be (big endian) Intel XScale IXP465 processor.
> The build tools were from snapgear, and the linux
> distribution was from the vendor, ADI (Sidewinder
> board). The kernel compiles file.
>
> When I run cvm:
>
> # ./cvm
> ./cvm: can't load library 'libdl.so.2'
> # add libdl.so.2 into lib
> # ./cvm
> libc.so.6: aborted attempt to load ./cvm!
> # add libc.so.6 into lib
> # ./cvm
> libc.so.6: aborted attempt to load ./cvm!
>
> libc.so.6 and libdl.so.2 both came from my toolchain
> (/usr/local/arm-linux/lib/be/)
>
> Here is the results from running file on various
> files in the system:
> # file cvm libc.so.6 libdl.so.2 libdl.so.0 libc.so.0
> ../bin/bash ../bin/busybox
> cvm: ELF 32-bit MSB executable, ARM,
> version 1 (ARM), for GNU/Linux 2.0.0, dynamically
> linked (uses shared libs), for GNU/Linux 2.0.0,
> stripped
> libc.so.6: ELF 32-bit MSB shared object, ARM,
> version 1 (ARM), for GNU/Linux 2.0.0, stripped
> libdl.so.2: ELF 32-bit MSB shared object, ARM,
> version 1 (ARM), for GNU/Linux 2.0.0, stripped
> libdl.so.0: ELF 32-bit MSB shared object, ARM,
> version 1 (ARM), stripped
> libc.so.0: ELF 32-bit MSB shared object, ARM,
> version 1 (ARM), stripped
> ../bin/bash: ELF 32-bit MSB executable, ARM,
> version 1 (ARM), for GNU/Linux 2.0.0, dynamically
> linked (uses shared libs), for GNU/Linux 2.0.0,
> stripped
> ../bin/busybox: ELF 32-bit MSB executable, ARM,
> version 1 (ARM), for GNU/Linux 2.0.0, dynamically
> linked (uses shared libs), for GNU/Linux 2.0.0,
> stripped
>
> bash and busybox run fine (they are built with the
> ADI linux distribution).
>
> Any ideas as to why it is not running?
>
> I would also be open to the idea of trying to compile
> cvm against uClibc (0.9.27 comes with the ADI
> distribution), anyone had any experience trying to
> get these two working together?

If you have the "ldd" command, what does it show for cvm?
There may be other libraries missing, such as pthreads.

Dean

lamsap
Offline
Joined: 2004-11-09
Points: 0

I have:

# ls -l
-rwxr-xr-x 1 0 0 3136947 cvm
lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ld-uClibc-0.9.27.so
-rwxr-xr-x 1 0 0 21312 ld-uClibc-0.9.27.so
-rwxr-xr-x 1 0 0 21312 ld-uClibc.so.0
-rw-r--r-- 1 0 0 276268 libc.so.0
-rw-r--r-- 1 0 0 10688 libcrypt-0.9.27.so
-rw-r--r-- 1 0 0 10688 libcrypt.so.0
-rw-r--r-- 1 0 0 7160 libdl-0.9.27.so
-rw-r--r-- 1 0 0 7160 libdl.so.0
-rwxr-xr-x 1 0 0 9496 libdl.so.2
-rw-r--r-- 1 0 0 53184 libm-0.9.27.so
-rw-r--r-- 1 0 0 53184 libm.so.0
-rw-r--r-- 1 0 0 1416 libnsl-0.9.27.so
-rw-r--r-- 1 0 0 1416 libnsl.so.0
-rw-r--r-- 1 0 0 68592 libpthread-0.9.27.so
-rw-r--r-- 1 0 0 68592 libpthread.so.0
-rw-r--r-- 1 0 0 1420 libresolv-0.9.27.so
-rw-r--r-- 1 0 0 1420 libresolv.so.0
-rw-r--r-- 1 0 0 1320 librt-0.9.27.so
-rw-r--r-- 1 0 0 1320 librt.so.0
-rw-r--r-- 1 0 0 276268 libuClibc-0.9.27.so
-rw-r--r-- 1 0 0 4120 libutil-0.9.27.so
-rw-r--r-- 1 0 0 4120 libutil.so.0

I can't ldd any files using the toolkit's ldd:
/usr/local/arm-linux/bin/ldd cvm
/usr/local/arm-linux/bin/ldd: line 132: /usr/local/arm-linux/lib/ld-linux.so.2: cannot execute binary file
/usr/local/arm-linux/bin/ldd: line 142: /usr/local/arm-linux/lib/ld-linux.so.2: cannot execute binary file
ldd: /usr/local/arm-linux/lib/ld-linux.so.2 exited with unknown exit code (126)

I am a bit suspect about libc.so.6 and libdl.so.2 since I got them from my toolchain (/usr/local/arm-linux/lib/be/libc.so.6 etc...), and were not generated while building the kernel... but the file command seems to think they are of the correct type.

Hinkmond Wong

Hi,

You can try this brute force way of looking for the missing lib*.so
dependencies:

On your Linux/x86 cross-compiler host system, try this Linux command
using the uClibc cvm binary you are having problems with:

% strings cvm | grep "^lib.*.so.*"

libpthread.so.0
libdl.so.2
libfloat.so
libc.so.6
libpthread.so.0

Does it show all the lib*.so files that you can find on your device?
Are any missing?

Hinkmond

phonemeadvanced@mobileandembedded.org wrote:
> I have:
>
> # ls -l
> -rwxr-xr-x 1 0 0 3136947 cvm
> lrwxrwxrwx 1 0 0 24 ld-linux.so.2 -> /lib/ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312 ld-uClibc-0.9.27.so
> -rwxr-xr-x 1 0 0 21312 ld-uClibc.so.0
> -rw-r--r-- 1 0 0 276268 libc.so.0
> -rw-r--r-- 1 0 0 10688 libcrypt-0.9.27.so
> -rw-r--r-- 1 0 0 10688 libcrypt.so.0
> -rw-r--r-- 1 0 0 7160 libdl-0.9.27.so
> -rw-r--r-- 1 0 0 7160 libdl.so.0
> -rwxr-xr-x 1 0 0 9496 libdl.so.2
> -rw-r--r-- 1 0 0 53184 libm-0.9.27.so
> -rw-r--r-- 1 0 0 53184 libm.so.0
> -rw-r--r-- 1 0 0 1416 libnsl-0.9.27.so
> -rw-r--r-- 1 0 0 1416 libnsl.so.0
> -rw-r--r-- 1 0 0 68592 libpthread-0.9.27.so
> -rw-r--r-- 1 0 0 68592 libpthread.so.0
> -rw-r--r-- 1 0 0 1420 libresolv-0.9.27.so
> -rw-r--r-- 1 0 0 1420 libresolv.so.0
> -rw-r--r-- 1 0 0 1320 librt-0.9.27.so
> -rw-r--r-- 1 0 0 1320 librt.so.0
> -rw-r--r-- 1 0 0 276268 libuClibc-0.9.27.so
> -rw-r--r-- 1 0 0 4120 libutil-0.9.27.so
> -rw-r--r-- 1 0 0 4120 libutil.so.0
>
> I can't ldd any files using the toolkit's ldd:
> /usr/local/arm-linux/bin/ldd cvm
> /usr/local/arm-linux/bin/ldd: line 132: /usr/local/arm-linux/lib/ld-linux.so.2: cannot execute binary file
> /usr/local/arm-linux/bin/ldd: line 142: /usr/local/arm-linux/lib/ld-linux.so.2: cannot execute binary file
> ldd: /usr/local/arm-linux/lib/ld-linux.so.2 exited with unknown exit code (126)
>
> I am a bit suspect about libc.so.6 and libdl.so.2 since I got them from my toolchain (/usr/local/arm-linux/lib/be/libc.so.6 etc...), and were not generated while building the kernel... but the file command seems to think they are of the correct type.
> [Message sent by forum member 'lamsap' (lamsap)]
>
> http://forums.java.net/jive/thread.jspa?messageID=210554
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
> For additional commands, e-mail: advanced-help@phoneme.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: advanced-unsubscribe@phoneme.dev.java.net
For additional commands, e-mail: advanced-help@phoneme.dev.java.net