Andre,
Pretty normal setup. Do you have support for
__attribute__((constructor,destructor)) in your compiler and libc?
Yes! Really, the only limitations is on how the mini-Linux kernel was
prepared. We suspect that it is a Montevista distribution compiled
without any shared object support. So, there is no /lib. I'd liken it
to booting a live disk.
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
You mean what you see as /mnt/DEVICE on your host is /mnt/hdd on your
target? Is it always /mnt/hdd
Yes, you assumed correctly!
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.
You want your app (or DirectFB in this case) to run from a different
--prefix than it was configured for?
I would advice against that... In general, you'll likely get problems
with many programs, e.g. not being able to find their data files etc.
So, normally (given my assumption above is correct), you'd
configure --prefix=/mnt/hdd
make DESTDIR=/mnt/DEVICE install
make DESTDIR=/opt/SDK install
You will also have to modify the *.pc and *.la files in /opt/SDK to
point to this (/opt/SDK) location, because they'll point to /mnt/hdd.
In DirectFB there might be a shortcut to this by using the
--with-sysroot= configure option. I haven't needed it till now, but it
seems, with this option you could
configure --prefix=/opt/SDK --with-sysroot=/mnt/hdd
It's not a usual auto* option, so other packages (in case you have any)
will still need to be built and post-install modified as described
above.
This all makes sense, but still assumes that there will be both
/mnt/hdd/etc/directfbrc and /mnt/hdd/etc/fb.modes files?
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.
Yes, you will have to do that, unless...
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.
... Oh, I thought you wanted dynamic linking.
For static-only linking all the prefix stuff etc is pretty irrelevant,
just --prefix and install to /opt/SDK and later
use /opt/SDK/bin/directfb-config when building/linking applications
against DirectFB.
It will tell you which objects need to be linked into your app.
You will likely need imageprovider, font, system and input drivers (to
be specified as arguments to directfb-config).
Ah, perfect. I think that this is exactly what I was looking for. I'll
give this a try! Is there a way to pass this to Glib? Whatever ends up
being the solution, I've been maintaining some documentation on the
steps taken. However, I'm still trying to keep the SDK as user friendly
as possible. Will this approach still require the RC and MODES files?
Since I really only have one graphics mode to support, 480x272, I'd
prefer to compile this in if possible.
The dlopen() comment was just for those applications which want to load
their own dependent shared objects or "modules" as the case may be. It
is not supported at the OS level.
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.
What device is this?
It's for the COWON O2 PMP. There's a small group of us trying to
replace much of the vendor supplied software and DirectFB is a pretty
critical layer that will open the door to vastly extending the
capability of the device. While it has a DaVinci TI product in it, they
have not fully exposed the driver in the kernel. An input driver for
DirectFB was fairly trivial, but we have more reverse engineering to
really take advantage of the DSP engine.
Sorry for being long-winded, but hopefully this detail helps.
I think it did a bit, hopefully ;-)
Cheers,
Andre'
Thanks again! This gives me some ideas I can follow up with.
-fred
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
