https://bugs.kde.org/show_bug.cgi?id=428909
--- Comment #22 from Paul Floyd <pjfl...@wanadoo.fr> --- (In reply to Mark Wielaard from comment #20) > I find the logic in the previous patch much easier to follow. The configure > tests look complex/fragile. Also I am not sure the first > ac_thread_fns_only_in_libc=yes is correct. Why couldn't those (or other) > functions then not also be in libpthread? Indeed I'm sure it is the case that functions can be in both libraries. I'm not sure which platforms use this, and which functions are impacted, but I believe that one way of doing things is to have stub functions in libc that are weak symbols and then to have the full implementations in libpthread. So when the application is not linked against libpthread you get single threaded behaviour. When libpthread is linked, the full versions get chosesn by the link loaded and the application runs multithreaded. ac_thread_fns_only_in_libc=yes is an empirical approximation to the truth based on my experience and a bit of trial and error. > Normally I would agree with Bart, but I think this is one example of when > configure tests are actually harder to keep correct than the simple ifdefs > based on platform. I'll wait to see what Bart says before proceeding. -- You are receiving this mail because: You are watching all bug changes.
