Danny Backx wrote: > On Mon, 2007-09-03 at 21:01 +0200, pgeorges wrote: >> Danny Backx a écrit : >>> HeapCompact is described on MSDN to be present on Windows CE 5 or >>> higher; my device has an older WinCE. Therefore when I add HeapCompact >>> to src/cegcc/importlibs/defs/coredll.def , and create a test application >>> that uses it, WinCE tells me it is not a valid Pocket PC application. >>> >>> You can try this on your PDA. Can you build the libcoredll.a or do you >>> need me to send you one ? > >> HeapCompact is indeed only available with WinCE 5 and higher, so it is >> not so important. But CreateToolhelp32Snapshot is more important, as it >> is present since Wince 3.0, so maybe it could be incorporated in binary >> releases. >> I will try to generate it by myself, thank you for your offer. > > Pedro, others, > > Would it be a good idea to generate multiple versions of some of the > libraries that we distribute ? > > An example : the line > ./mkimport.sh $defdir/coredll.def $outputdir || exit > in src/cegcc/importlibs/build.sh creates > /opt/cegcc/arm-wince-cegcc/lib/libcoredll.a > based on the input file src/cegcc/importlibs/defs/coredll.def whose > contents is a list of supported APIs. > > As we know several versions of WinCE are popular, we only distribute one > version of our toolset. > > We could have support for more than one version of WinCE by creating a > second version of coredll.def and having an additional line in build.sh, > such as > ./mkimport.sh $defdir/coredll5.def $outputdir || exit > > We could even have a "master" file that defines multiple OS levels, and > generate coredll.def, coredll5.def and so on from it. >
> How good or bad an idea is this ? > "Maintainance burden"? We already have _WIN32_WCE for that. The symbols that don't exist in say, CE < 5 should be guarded with #ifdef _WIN32_WCE >= 0x500, as we already do. If we don't in some case, then it is a bug. Until it isn't needed, that is, until we find a dll that exports a function by ordinal only, and that ordinal is different in different CE versions, I'm opposed to it. Also, you are looking at the old way of generating the import libs, which cegcc still uses. mingw32ce properly builds them when building src/w32api - which also means it already builds libtoolhelp.a. Look into src/w32api/libce/*. I never took the time to convert cegcc to it. Cheers, Pedro Alves ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
