Hi Fred, I think now I see what you want to do, but still not 100% sure...
On Sat, 2009-03-07 at 10:19 -0700, Fred R. Beck wrote: > 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(). Pretty normal setup. Do you have support for __attribute__((constructor,destructor)) in your compiler and libc? > 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 > 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. > 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). > 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? > Sorry for being long-winded, but hopefully this detail helps. I think it did a bit, hopefully ;-) Cheers, Andre' _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
