On Thu, 3 Jul 2008, Brian Dessent wrote:
module_la_LIBADD = evas_wince_gapi.o However, if you try that with a libtool library you run into (B), with something like: libtool: link: cannot build libtool library `module.la' from non-libtool objects on this host: evas_wince_gapi.o This is where it gets ugly. You need to sneak the object in past libtool's eyes with something like: module_la_LDFLAGS = -Xlinker evas_wince_gapi.o But now there's a new problem, in that automake will no longer see this object as being a dependency of module.la, so you've got to explicitly mention it otherwise you're back to the issue in (A) of it never being built: module_la_DEPENDENCIES = evas_wince_gapi.o With those two lines I think you'll find success, but this is far from a clean solution. Perhaps someone that is more familiar with libtool can comment on the issue. From a libtool standpoint, resource objects aren't really the same as code objects as they have no PIC-ness, and don't even have any symbols that are referenced from other objects. They are just blobs of specially formatted data that get copied into the resource section of the final image during linking.
As Ralf said, I added LT_PROG_RC in my configure.ac; it sets RC to the correct windres (arm-wince-cegcc-windres as i'm cross-compiling).
With the 2 commands above and the rule, it seems to work. libtool link command is:
arm-wince-cegcc-g++ -shared (some .o, .dll.a) -Wl,evas_wince_gapi.o -o .libs/module.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/module.dll.a 1) is it normal to have -Wl,evas_wince_gapi.o ? 2) there are 2 -Xlinker. is it useful to add the one in module_la_LDFLAGS ? I can't test the result (it's a friend who can, later today) thank you for both of you Vincent Torri
