Andre,
I appreciate the response; however, maybe I wasn't clear. I have 3
seperate states:
1) I "install" into an SDK area that I am assembling, with a
toolchain, to share with others.
My SDK root is located notionally at: /opt/SDK. The SDK is
built for an ARM architecture, not my host system.
The SDK is all static with no shared objects. However, it does
support dlopen().
2) My embedded device mounts notionally at: /mnt/DEVICE, and does
NOT mount the root of it's runtime filesystem.
3) At runtime, the embedded device sees the #2 filesystem as: /mnd/hdd
I can force the embedded device to mount the same path that it does
during runtime on my host; however, I cannot guarantee that users of the
SDK and toolchain can do the same. Since the "make install" installs
into a SDK, there is going to have to be a second step to migrate the
necessary support files to the correct locations on the embedded device
- should that be required.
Since I do not have a interactive control on how applications are
started due to there being only a touchscreen input, providing command
line arguments to override default locations for modules and configs is
a bit difficult - but not impossible. This is currently how I am
testing, by using a loader to exec() my test application with command
line arguments.
Ideally, since the embedded device only supports statically built
objects, I would prefer to only install the built and linked application
rather than it coupled with a support infrastructure. If this is not
possible with DirectFB, then so be it. I just don't want to eat up
limited storage space that would be hidden to the user if they were to
remove the application.
I have suspicions that all of this IS possible as the vendor for the
embedded device has provided an application which uses GTK. There are
no directfb configs or system modules loaded, and there is only a
/dev/fb0 device. I do not find any indication of directfb when
disassembling though. And despite being asked, they have chosen to not
expose their software or the complete SDK they used... we asked.
Sorry for being long-winded, but hopefully this detail helps.
-fred
Andre DRASZIK wrote:
Hi,
On Sat, 2009-03-07 at 00:07 -0700, Fred R. Beck wrote:
Since my runtime environment does not map to the SDK install area
specified by the --prefix command, I'm at a loss as to what all I need
to install on the target device and how I can point the compiled
application to find everything
Hm, maybe I don't get your point, but are you saying you can't see your
target fs from your host? If not, --prefix is the prefix to your runtime
paths on the target, as seen from the target.
So you do ./configure ... --prefix=/mystuff and build, and after
installing your directfb onto the target fs it will look for
inputdrivers etc. in /mystuff/lib/directfb-1.3.0/inputdrivers etc.
To install this after compilation from your host you do
make DESTDIR=/targetfs/as/seen/from/the/host install
Alternatively, you can specify --libdir= --syconfdir= (and many more)
during configure and/or
make prefix=... libdir=... sharedstatedir=... (and many others) install
for installing if you want a more fine grained control of the directory
layout.
Cheers,
Andre'
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
