> My concern (as a commercial developer that releases > static builds) is not whether the code is used, > but that it's in the lib at all. > > True: if the code is not called, it shouldn't > appear in the linked executables by optimization. > And legally I imagine that's all that matters.
That's my assumption too; although it is in the sourcebase, it doesn't actually (seem to) appear in the binary on any host that provides an implementation of scandir(). So we are not "using" it and all is well, Probably... IANAL... > And in my quick builds on linux, if I put some unique > strings in the body of the scandir code and do a static > build against the lib, I don't see that string in the > executable, so offhand it seems app developers have > nothing to worry about regarding released binaries. > > Still though, it should be "fixed", by which > I mean either rewritten or removed. Yup. If we can determine which hosts actually need it, and the answer turns out to be none, then removal would be the easiest option. On the other hand, a "volunteer's worth ten pressed-men" as the saying goes, and if you were going to take a stab at a clean replacement, we could bundle that under the fltk license and that also resolves things (without anybody having to try and figure out why we still have it after all this time...!) _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
