On 04.03.2010 at 13:06, MacArthur, Ian (SELEX GALILEO, UK) wrote: > Again, quoting from the v8a change.log file: > > "Add data source and destination managers for read from and write to > memory buffers. New API functions jpeg_mem_src and jpeg_mem_dest."
I must have overlooked that. > I was mainly thinking that the bundled lib would be statically linked > anyway, so ABI differences are a Don't Care. I was more thinking of source compatibility here. There shouldn'n be any ABI problems, especially because the bundled jpeg lib has another name. > The API is not changed AFAIK. ... but extended. If someone distributes sources and relies on new features in the bundled libjpeg (or calls a future FLTK function that would rely on it), and someone else with a system libjpeg v6 who configured FLTK to use the system jpeg libs (which is the default) would try to compile this program, then his version would fail. For instance, if our future FLTK function to read jpeg images from memory would use jpeg v8 features, then we would need a feature test to decide if this is available on the current system, and this would fail on the target system with a system jpeg lib. In the best case we would have a fallback, using only features from v6 (*), and in any other case this function would fail more or less user friendly. --- (*) but then: why bother having the v8 function at all? OTOH we could force configure to use the bundled lib, if the system lib doesn't have a needed function. Well, that's possible... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
