Hi handheld lovers,
for amusement I wrote attached script to compile
a babyGRASS from a standard GRASS 5 source code version.
It will generate a few important commands based on shared GRASS
libraries. The size is 2.8MB on Linux. Next step for us is
to compile it on the Skiff cluster for iPAQs.
(Phone Tracker Free | Mobile Tracker | Cell Phone Tracking App)
The script is not very elegant, but maybe someone will find
it useful.
Cheers
Markus
make_babyGRASS.sh (4.48 KB)
Markus Neteler wrote:
for amusement I wrote attached script to compile
a babyGRASS from a standard GRASS 5 source code version.It will generate a few important commands based on shared GRASS
libraries. The size is 2.8MB on Linux.
If you're looking to save memory, generate stripped binaries, e.g.
LDFLAGS=-s ./configure ...
You could also try optimising for size:
CFLAGS=-Os LDFLAGS=-s ./configure ...
If you really want to save memory, you need a display driver which
doesn't require X. E.g. a modified PNG (i.e. GD) driver which outputs
to a framebuffer device.
--
Glynn Clements <glynn.clements@virgin.net>
On Apr 24, Glynn Clements wrote:
> If you're looking to save memory, generate stripped binaries, e.g.
> You could also try optimising for size:
Both good points.
> If you really want to save memory, you need a display driver which
> doesn't require X. E.g. a modified PNG (i.e. GD) driver which outputs
> to a framebuffer device.
Nah... X is really not as large as one might think. The X server used
on iPAQs, (using kdrive aka TinyX), weighs in at 733kB. Together with
core libraries and fonts, the whole package can come in at about 2MB.
Getting rid of X would give up so much functionality, there's really
no savings here that would be worth the effort.
-Carl
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
On Apr 24, Markus Neteler wrote:
> for amusement I wrote attached script to compile
> a babyGRASS from a standard GRASS 5 source code version.
>
> It will generate a few important commands based on shared GRASS
> libraries. The size is 2.8MB on Linux. Next step for us is
> to compile it on the Skiff cluster for iPAQs.
> (http://www.handhelds.org/projects/skiffcluster.html)
Markus,
Many thanks at a first cut at this!
What I am planning on doing is making a fine-grained partitioning of
GRASS into many small packages with dependency relationships. I
imagine splitting functionality based on task, data types, file
formats, etc.
This will have general applicability to systems such as Debian that
handle package dependency trees quite nicely, as well as to handheld
systems, (such as Familiar which has similar package management
capability).
That way, if you really do need to r.in.tiff, (or anything else), on
your handheld for whatever reason, you'll still have the option of
installing the package to do it, (without having to install all 32MB
of GRASS).
-Carl
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
On Apr 24, Markus Neteler wrote:
On Wed, Apr 24, 2002 at 03:35:07PM +0000, Carl Worth wrote:
On Apr 24, Glynn Clements wrote:
> If you're looking to save memory, generate stripped binaries, e.g.
> You could also try optimising for size:Both good points.
Thanks - have update that. I currently face the problem that
mk/vars.mk
does not get the prefix/bindir from configure. But that's
eventually not yet implemented (will find a workaround).
> If you really want to save memory, you need a display driver which
> doesn't require X. E.g. a modified PNG (i.e. GD) driver which outputs
> to a framebuffer device.Nah... X is really not as large as one might think. The X server used
on iPAQs, (using kdrive aka TinyX), weighs in at 733kB. Together with
core libraries and fonts, the whole package can come in at about 2MB.Getting rid of X would give up so much functionality, there's really
no savings here that would be worth the effort.-Carl
Markus
Markus Neteler wrote:
> > If you're looking to save memory, generate stripped binaries, e.g.
> > You could also try optimising for size:
>
> Both good points.Thanks - have update that. I currently face the problem that
mk/vars.mk
does not get the prefix/bindir from configure. But that's
eventually not yet implemented (will find a workaround).
What use would that be?
The only part of the build process which should need to know the
prefix is the "install" target.
--
Glynn Clements <glynn.clements@virgin.net>
On Wed, Apr 24, 2002 at 05:59:37PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> > > If you're looking to save memory, generate stripped binaries, e.g.
> > > You could also try optimising for size:
> >
> > Both good points.
>
> Thanks - have update that. I currently face the problem that
> mk/vars.mk
> does not get the prefix/bindir from configure. But that's
> eventually not yet implemented (will find a workaround).What use would that be?
The only part of the build process which should need to know the
prefix is the "install" target.
my ideas was to build standard GRASs and babyGRASS in the same
directory (with shared libs). Currently babyGRASS compilation is
overwriting everything in dist.$ARCH. I wanted to write
to ./babyGRASS/dist.$ARCH to protect the standard compilation.
A bit tricky perhaps.
What you suggest in the mk/README (cd ~/grass-build) is not
clear to me. But it may be the solution for my problem.
Markus
Markus Neteler wrote:
> > > > If you're looking to save memory, generate stripped binaries, e.g.
> > > > You could also try optimising for size:
> > >
> > > Both good points.
> >
> > Thanks - have update that. I currently face the problem that
> > mk/vars.mk
> > does not get the prefix/bindir from configure. But that's
> > eventually not yet implemented (will find a workaround).
Actually, mk/vars.mk does get these:
prefix = /opt
exec_prefix = ${prefix}
UNIX_BIN = /usr/local/bin
> What use would that be?
>
> The only part of the build process which should need to know the
> prefix is the "install" target.my ideas was to build standard GRASs and babyGRASS in the same
directory (with shared libs). Currently babyGRASS compilation is
overwriting everything in dist.$ARCH. I wanted to write
to ./babyGRASS/dist.$ARCH to protect the standard compilation.
A bit tricky perhaps.
Right, but that isn't related to prefix/bindir; those are the
installation paths. The staging paths are GISBASE (dist.<arch>) and
GRASS_BIN (bin.<arch>).
What you suggest in the mk/README (cd ~/grass-build) is not
clear to me. But it may be the solution for my problem.
A separate build directory is probably the right solution in this
case, as nothing should be shared. A normal GRASS build should either
be debuggable (-g), or optimised for speed (-O2). A "baby" GRASS
should be optimised for size (-Os), and not have debug info.
Note that "~/grass-build" is just an example. You can have as many
build directories as you like. The makefiles which are generated by
mk/mkmakefiles (or "make makefiles") depend only upon the Gmakefiles;
they will work for any build directory, and any platform.
Also, the alternate build mechanism doesn't write anything to the
source directory, so you don't need to clean anything between builds,
and you can run multiple builds concurrently.
--
Glynn Clements <glynn.clements@virgin.net>
On Wed, Apr 24, 2002 at 04:12:36PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> for amusement I wrote attached script to compile
> a babyGRASS from a standard GRASS 5 source code version.
>
> It will generate a few important commands based on shared GRASS
> libraries. The size is 2.8MB on Linux.If you're looking to save memory, generate stripped binaries, e.g.
LDFLAGS=-s ./configure ...
You could also try optimising for size:
CFLAGS=-Os LDFLAGS=-s ./configure ...
Thanks for the hint - the size is shrinked by around 50% to
1.7MB.
If anyone else is interested, I have another script now to
extract babyGRASS from a common code directory into a new
tarball. Also the compile script is improved. Let me know,
then I send it to you.
Currently we cannot login into the Skiff cluster (down), otherwise
inital GRASS/iPAQ binaries would probably already available.
Cheers
Markus
On Apr 29, Markus Neteler wrote:
> Thanks for the hint - the size is shrinked by around 50% to
> 1.7MB.
Excellent.
> If anyone else is interested, I have another script now to
> extract babyGRASS from a common code directory into a new
> tarball. Also the compile script is improved. Let me know,
> then I send it to you.
Markus, I'd be interested in this. Perhaps you could commit it into
CVS somewhere.
> Currently we cannot login into the Skiff cluster (down), otherwise
> inital GRASS/iPAQ binaries would probably already available.
Other options are to compile GRASS natively on an iPAQ or using a
cross-compiler, (which I have done successfully for very large portions
of GRASS). I have both options readily available here, so I can
compile up this lightweight GRASS distribution and contribute it to
the Familiar Linux distribution for easy installation on handhelds.
-Carl
On Mon, Apr 29, 2002 at 05:27:24PM +0000, Carl Worth wrote:
On Apr 29, Markus Neteler wrote:
> Thanks for the hint - the size is shrinked by around 50% to
> 1.7MB.Excellent.
Yes - the command included are:
- db.* modules
- g.gisenv
- d.mon
- d.rast
- d.vect
- d.sites
- d.erase
- d.what.rast
- d.what.vect
- d.what.sites
- d.measure
- d.pan
- d.zoom
- g.region/cmd
- manage (g.list, g.remove etc)
- r.in.ascii
- s.in.ascii
Of course the script can be easily extended.
> If anyone else is interested, I have another script now to
> extract babyGRASS from a common code directory into a new
> tarball. Also the compile script is improved. Let me know,
> then I send it to you.Markus, I'd be interested in this. Perhaps you could commit it into
CVS somewhere.
OK - do you have a suggestion for a place?
Maybe in
tools/
?
> Currently we cannot login into the Skiff cluster (down), otherwise
> inital GRASS/iPAQ binaries would probably already available.Other options are to compile GRASS natively on an iPAQ or using a
cross-compiler, (which I have done successfully for very large portions
of GRASS). I have both options readily available here, so I can
compile up this lightweight GRASS distribution and contribute it to
the Familiar Linux distribution for easy installation on handhelds.
That we didn't try yet. Perhaps we should also add a
GRASS/Handhelds
web page to stimulate further interest.
Markus
Hi,
meanwhile we have compiled a binary version for iPAQ on
the skiff-cluster (I fixed some bugs in my script).
Only one lib cannot be compiled, the gcc crashes:
./gmake5 src/libes/dig_atts
make: Entering directory
'/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts'
mkdir -p /home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts
make -f makefile
make[1]: Entering directory
'/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts'
gcc -shared -o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/libgrass_dig_atts.so.5.0.0
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/atts_init.o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/read_att.o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/write_att.o
-L/home/guest/stankovic@itc.it/babyGRASS_src/src/libes
-Wl,-rpath-link,/home/guest/stankovic@itc.it/babyGRASS_src/src/libes -s
-lgrass_gis && ln -sf libgrass_dig_atts.so.5.0.0
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/libgrass_dig_atts.so
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
make[1]: ***
[/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/libgrass_dig_atts.so.5.0.0]
Error 1
make[1]: Leaving directory
'/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts'
make: *** [dir] Error 2
make: Leaving directory
'/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts'
Architecture is:
uname -a
Linux skiffcluster4.handhelds.org 2.4.0-test1-ac7-rmk1-crl2 #15 Fri Jun 16
11:24:53 EDT 2000 armv4l unknown
I don't know what I can do, the libgrass_dig_atts.so is needed for all
vector libs and modules. As far as I know such signal 11 is worst case...
All other libs compile (except for the libgrass_dig_atts.so dependency).
Markus
So,
meanwhile the precompiled iPAQ binaries are installed.
Unfortunately we face a segmentation fault everywhere.
E.g. the Init.sh calls $ETC/set_data:
strace /tmp/dist.armv4l-unknown-linux-gnu/etc/set_data
[...]
open("/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so",
O_RDONLY) =
3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\33\0"..., 1024) =
1024
SYS_197(0x3, 0xbfffef9c, 0xbfffef9c, 0x664, 0x3) = 0
mmap(0, 59820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x402c3000
mprotect(0x402ca000, 31148, PROT_NONE) = 0
mmap(0x402cb000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x402cb000
close(3) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40019000
mprotect(0x4002c000, 286720, PROT_READ|PROT_WRITE) = 0
mprotect(0x4002c000, 286720, PROT_READ|PROT_EXEC) = 0
Segmentation fault
Looking at the dependencies:
ldd /tmp/dist.armv4l-unknown-linux-gnu/etc/set_data
/tmp/dist.armv4l-unknown-linux-gnu/etc/set_data:
libgrass_edit.so =>
/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_edit.so (0x4001f000)
libgrass_gis.so =>
/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_gis.so (0x4002c000)
libgrass_vask.so =>
/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_vask.so (0x400b6000)
libncurses.so.5 => /lib/libncurses.so.5 (0x400c3000)
libm.so.6 => /lib/libm.so.6 (0x4010f000)
libz.so.1 => /usr/lib/libz.so.1 (0x4018f000)
libc.so.6 => /lib/libc.so.6 (0x401a7000)
libgrass_datetime.so =>
/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so (0x402c3000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
... all libs found.
The same with modules:
strace /tmp/dist.armv4l-unknown-linux-gnu/etc/bin/cmd/g.gisenv
[...]
open("/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so",
O_RDONLY) =
3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\33\0"..., 1024) =
1024
SYS_197(0x3, 0xbffff004, 0xbffff004, 0x664, 0x3) = 0
mmap(0, 59820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4025d000
mprotect(0x40264000, 31148, PROT_NONE) = 0
mmap(0x40265000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x40265000
close(3) = 0
mprotect(0x4001f000, 286720, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001f000, 286720, PROT_READ|PROT_EXEC) = 0
Segmentation fault
I am a bit in the dark here - do we have to install 'gdb' on iPAQ?
The system is:
uname -a
Linux familiar 2.4.16-rmk1 #5 Thu Jan 31 12:06:57 EST 2002 armv4l unknown
Carl, any ideas?
Thanks!
Markus
PS: I've just uploaded the latest baby* scripts to CVS: handheld/
On Apr 30, Markus Neteler wrote:
> Carl, any ideas?
Markus, I'm not sure why things are crashing on you.
> PS: I've just uploaded the latest baby* scripts to CVS: handheld/
I'm trying these out with my cross-compiler now. Things appear to have
compiled fine, but when I try to to run GRASS I find that
grass5/etc/lock does not exist, (I linked it to /bin/true to push past
this), and then grass5/etc/set_data does not exist.
Any suggestions where I might look to see why these didn't get
compiled?
Since, I'm going through it, I thought I would point out the ways in
which GRASS is hard to cross-compile, along with some suggested fixes:
1) configure tries to compile and run a program to determine the
number of arguments for setpgrp.
Workaround: Delete AC_FUNC_SETPGRP, run autoconf, run ./configure,
edit src/include/config.h to define SETPGRP_VOID.
Proposal: ??? (This is a long-standing frustration with autoconf)
2) The build process tries to compile, then execute nad2bin. I
understand that this is an attempt to create binary files with the
correct endian-ness, but it breaks cross-compilation.
Workaround: I just compiled nad2bin natively, then continued the
build. I think I'm OK, (eg. lucky), here since x86 and arm are the
same endian-ness. However, now an unusable nad2bin is being
installed with GRASS. Is GRASS going to execute this program during
normal operation?
Proposal: If GRASS does not execute nad2bin at runtime, then we
just need to come up with a mechanism for two different compilers
for native cs. cross-compilation. Then, nad2bin could be installed
using the native compiler, while all other compilation would use
the cross compiler.
On the other hand, if GRASS does execute nad2bin during runtime,
could we perhaps postpone the compile-time nad2bin calls until
run-time? This might be awkward, but it would at least enable
cross-compilation.
I'm open to any reactions/suggestions.
-Carl
--
Carl Worth
USC Information Sciences Institute cworth@east.isi.edu
3811 N. Fairfax Dr. #200, Arlington VA 22203 703-812-3725
Carl Worth wrote:
2) The build process tries to compile, then execute nad2bin. I
understand that this is an attempt to create binary files with the
correct endian-ness, but it breaks cross-compilation.Workaround: I just compiled nad2bin natively, then continued the
build. I think I'm OK, (eg. lucky), here since x86 and arm are the
same endian-ness. However, now an unusable nad2bin is being
installed with GRASS. Is GRASS going to execute this program during
normal operation?Proposal: If GRASS does not execute nad2bin at runtime, then we
just need to come up with a mechanism for two different compilers
for native cs. cross-compilation. Then, nad2bin could be installed
using the native compiler, while all other compilation would use
the cross compiler.On the other hand, if GRASS does execute nad2bin during runtime,
could we perhaps postpone the compile-time nad2bin calls until
run-time? This might be awkward, but it would at least enable
cross-compilation.
Carl,
I don't think nad2bin is executed at runtime by GRASS, but it can be
important that the nad2bin that is executed be one that matches the
architecture that will be using the output binary files. Note that this
isn't just an endian issue, the produced binary files will also be useless
if structure packing is different on the different architectures.
I personally think that PROJ.4 ought to work towards a new architecture
independent format for the grid shift files. This really wouldn't be hard.
or significantly impair performance.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
Markus Neteler wrote:
meanwhile we have compiled a binary version for iPAQ on
the skiff-cluster (I fixed some bugs in my script).
Only one lib cannot be compiled, the gcc crashes:gcc -shared -o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/libgrass_dig_atts.so.5.0.0
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/atts_init.o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/read_att.o
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/dig_atts/write_att.o
-L/home/guest/stankovic@itc.it/babyGRASS_src/src/libes
-Wl,-rpath-link,/home/guest/stankovic@itc.it/babyGRASS_src/src/libes -s
-lgrass_gis && ln -sf libgrass_dig_atts.so.5.0.0
/home/guest/stankovic@itc.it/babyGRASS_src/src/libes/libgrass_dig_atts.so
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
I can only presume that something has triggered a bug in the linker.
The only thing which I can suggest is editing src/libes/dig_atts/makefile
and mk/mid.mk to make the dig_atts library a static library.
--
Glynn Clements <glynn.clements@virgin.net>
Markus Neteler wrote:
meanwhile the precompiled iPAQ binaries are installed.
Unfortunately we face a segmentation fault everywhere.
E.g. the Init.sh calls $ETC/set_data:strace /tmp/dist.armv4l-unknown-linux-gnu/etc/set_data
[...]
open("/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so",
O_RDONLY) =
3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\33\0"..., 1024) =
1024
SYS_197(0x3, 0xbfffef9c, 0xbfffef9c, 0x664, 0x3) = 0
mmap(0, 59820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x402c3000
mprotect(0x402ca000, 31148, PROT_NONE) = 0
mmap(0x402cb000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x402cb000
close(3) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40019000
mprotect(0x4002c000, 286720, PROT_READ|PROT_WRITE) = 0
mprotect(0x4002c000, 286720, PROT_READ|PROT_EXEC) = 0
Segmentation fault
I am a bit in the dark here - do we have to install 'gdb' on iPAQ?
I'm not sure that gdb will help; it might not be getting as far as
calling main().
Try running strace on some other program, to see what happens next. On
Linux/x86, there is a bit more startup code before main gets called.
If it isn't reaching main(), then:
a) gdb won't help, and
b) the problem would appear to be with the shared libraries.
Maybe some other switches are required for ARM; the "gcc" Info file
lists quite a few ARM-specific options. Do you have any source code
which successfully builds and uses shared libraries which you could
use as a reference?
--
Glynn Clements <glynn.clements@virgin.net>
On Apr 30, Frank Warmerdam wrote:
> I don't think nad2bin is executed at runtime by GRASS, but it can be
> important that the nad2bin that is executed be one that matches the
> architecture that will be using the output binary files. Note that this
> isn't just an endian issue, the produced binary files will also be useless
> if structure packing is different on the different architectures.
Good point. This is of course true, (and likely to bite me in the x86
vs. arm case).
> I personally think that PROJ.4 ought to work towards a new architecture
> independent format for the grid shift files. This really wouldn't be hard.
> or significantly impair performance.
I agree.
-Carl
Carl Worth wrote:
> PS: I've just uploaded the latest baby* scripts to CVS: handheld/
I'm trying these out with my cross-compiler now. Things appear to have
compiled fine, but when I try to to run GRASS I find that
grass5/etc/lock does not exist, (I linked it to /bin/true to push past
this), and then grass5/etc/set_data does not exist.Any suggestions where I might look to see why these didn't get
compiled?Since, I'm going through it, I thought I would point out the ways in
which GRASS is hard to cross-compile, along with some suggested fixes:1) configure tries to compile and run a program to determine the
number of arguments for setpgrp.Workaround: Delete AC_FUNC_SETPGRP, run autoconf, run ./configure,
edit src/include/config.h to define SETPGRP_VOID.Proposal: ??? (This is a long-standing frustration with autoconf)
if [ "$cross_compiling" = "yes" ] then
AC_TRY_COMPILE(...)
else
AC_FUNC_SETPGRP
fi
Of course, this assumes that the headers include correct prototypes;
if they just use e.g. "extern int setpgrp();", there's no way to tell.
2) The build process tries to compile, then execute nad2bin. I
understand that this is an attempt to create binary files with the
correct endian-ness, but it breaks cross-compilation.
Right. The same situation exists for src/fonts/for_grass.
Workaround: I just compiled nad2bin natively, then continued the
build. I think I'm OK, (eg. lucky), here since x86 and arm are the
same endian-ness. However, now an unusable nad2bin is being
installed with GRASS. Is GRASS going to execute this program during
normal operation?
No.
Proposal: If GRASS does not execute nad2bin at runtime, then we
just need to come up with a mechanism for two different compilers
for native cs. cross-compilation. Then, nad2bin could be installed
using the native compiler, while all other compilation would use
the cross compiler.
As Frank pointed out, this won't work for nad2bin, as the binary
output files are platform-specific.
Ultimately, we need to:
a) modify the build procedure not to run these "compilers" when
cross-compiling, and
b) provide scripts which would complete the build procedure on the
target system.
--
Glynn Clements <glynn.clements@virgin.net>
On Tue, Apr 30, 2002 at 06:56:10PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
> meanwhile the precompiled iPAQ binaries are installed.
> Unfortunately we face a segmentation fault everywhere.
> E.g. the Init.sh calls $ETC/set_data:
>
> strace /tmp/dist.armv4l-unknown-linux-gnu/etc/set_data
> [...]
> open("/tmp/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so",
> O_RDONLY) =
> 3
> read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\33\0"..., 1024) =
> 1024
> SYS_197(0x3, 0xbfffef9c, 0xbfffef9c, 0x664, 0x3) = 0
> mmap(0, 59820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x402c3000
> mprotect(0x402ca000, 31148, PROT_NONE) = 0
> mmap(0x402cb000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
> 0x402cb000
> close(3) = 0
> mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
> 0x40019000
> mprotect(0x4002c000, 286720, PROT_READ|PROT_WRITE) = 0
> mprotect(0x4002c000, 286720, PROT_READ|PROT_EXEC) = 0
> Segmentation fault> I am a bit in the dark here - do we have to install 'gdb' on iPAQ?
I'm not sure that gdb will help; it might not be getting as far as
calling main().Try running strace on some other program, to see what happens next. On
Linux/x86, there is a bit more startup code before main gets called.If it isn't reaching main(), then:
a) gdb won't help, and
b) the problem would appear to be with the shared libraries.
Maybe some other switches are required for ARM; the "gcc" Info file
lists quite a few ARM-specific options. Do you have any source code
which successfully builds and uses shared libraries which you could
use as a reference?
Hi,
some news on GRASS/iPAQ:
We get inside GRASS shell when we start it with path to LOCATION as
parameter (bypassing the crashing $ETC/set_data). All modules are (still)
crashing.
E.g.
cd /grass/dist.armv4l-unknown-linux-gnu/etc/bin/cmd
strace g.list
[...]
open("/grass/dist.armv4l-unknown-linux-gnu/lib/libgrass_datetime.so",
O_RDONLY) = 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\210\33\0"..., 1024) =
1024
SYS_197(0x3, 0xbfffee34, 0xbfffee34, 0x664, 0x3) = 0
mmap(0, 59820, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4025d000
mprotect(0x40264000, 31148, PROT_NONE) = 0
mmap(0x40265000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) =
0x40265000
close(3) = 0
mprotect(0x4001f000, 286720, PROT_READ|PROT_WRITE) = 0
mprotect(0x4001f000, 286720, PROT_READ|PROT_EXEC) = 0
Segmentation fault
For comparison some working programs:
#--------------------------------
strace /bin/ping
[...]
read(3, "# /etc/protocols:\n# $Id: protoco"..., 4096) = 1748
close(3) = 0
munmap(0x40016000, 4096) = 0
socket(PF_INET, SOCK_RAW, IPPROTO_ICMP) = 3
SYS_199(0x40136ac0, 0xbffffbf0, 0x150c, 0x7dc, 0xbffffd04) = 0
msgget(IPC_PRIVATE, IPC_EXCL|IPC_NOWAIT|0x200b090|0220) = 0
write(2, "usage: ping [-LRdfnqrv] [-c coun"..., 125usage: ping [-LRdfnqrv]
[-c count] [-i wait] [-l preload]
[...]
#---------------------------------
strace /bin/gzip
[...]
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\1\1\1a\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\270\4\2\000"...,
1024) =
1024
SYS_197(0x3, 0xbffff0f0, 0xbffff0f0, 0x664, 0x3) = 0
mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x40018000
mmap(0, 1161272, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001f000
mprotect(0x4012a000, 67640, PROT_NONE) = 0
mmap(0x4012f000, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0x108000) = 0x4012f000
mmap(0x40137000, 14392, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40137000
close(3) = 0
munmap(0x40016000, 4540) = 0
getpid() = 381
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x2003f10, [INT], SA_RESTART|0x4000000}, {SIG_IGN}, 8)
= 0rt_sigaction(SIGTERM, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x2003f10, [TERM], SA_RESTART|0x4000000}, {SIG_IGN},
8) = 0
rt_sigaction(SIGHUP, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, {0x2003f10, [HUP], SA_RESTART|0x4000000}, {SIG_IGN}, 8)
= 0ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(2, "gzip: compressed data not writte"..., 78gzip: compressed data not
writ
[...]
(sorry for this copy-paste)
We are still clueless how to continue.
I have put the dumpspecs of Skiffcluster (ARM/Linux) here:
http://mpa.itc.it/markus/tmp/gcc_dumpspecs_arm.txt
(4kb)
These flags and options do not tell me anything 
Carl... Glynn...
Thanks,
Markus