Hi folks, Writing software for various systems and platforms is challenging, but tidy has done it, duktape has done it, and I'm sure we can too.
I'm 99% sure the recent tidy comfusion is incompatibility between headers and linked in library. This is sometimes caused by distros that already have tidy, but an older version, so a packager brings in a new version and builds and that's fine but then there are two such libraries, if he doesn't remove the old one, and one can glom on to the old library, and just anything can happen after that. > I am very alarmed by the 'findTidy.cmake' change - I can remove these lines if you wish, I am the arbiter, is there another approach that might work better for these bsd folks? I will mostly stay out of the middle of this one and you can collectively advise me. One thing we recommend is when you must bring in a newer tidy to build edbrowse you *have* to delete the old one and make the new one the only tidy in the distro, then of course that will be the only one cmake can find and there shouldn't be trouble. It is clear that the thread type is suppose to be opaque, and accessed only through api, so I changed to pthread_equal as you suggest. Karl Dahlke
