Hi, Sorry for the delayed answer.
On 20/06/11 19:52, Nick Mathewson wrote: >> But since I got your attention, I'll plug a follow-up question about the >> build-system: what's the reason for setting BUILD_WITH_NO_UNDEFINED only >> for cygwin and win32? >> >> I'm currently patching the packages to always use it (reasons outlined >> here[0]) and haven't run into any problems, but maybe I'm overlooking >> something obvious again. (snip) >> If not, would you accept a patch to turn it into a configure-time >> option? (besides keeping it on for cygwin and win32, of course) > > I'm not sure I understand the article you linked to. What's the > impact here, and what are the potential advantages/disadvantages? This is mostly a packaging issue and as such shouldn't have any direct influence on the code. It's more of a concern for distributions. Also, the "-no-undefined" flag isn't as important as explicitly linking all other libevent-* libs against libevent-core, which also gets done only if BUILD_WITH_NO_UNDEFINED is turned on. The following is a rough explanation, so if you're not interested feel free to skip it (specially since I'm no ld-specialist, so it might not be completely correct and/or sound overly pedantic). The real issue actually involves the --as-needed and --no-add-needed ld options. The first avoids adding spurious DT_NEEDED headers to libraries, by only adding headers for libraries whose symbols actually get used (in case someone added an extra unneeded -lwhatever, for instance). The second (--no-add-needed) trims in the opposite direction: it avoids looking for symbols in indirectly depended libs, i.e.: without --no-add-needed, if your lib A links against lib B and my program/lib C links only against lib A, but also uses symbols in lib B, it would compile and work, because symbols would be looked for recursively. However, if you suddenly changed lib A to not link against lib B, prog/lib C won't compile without manual intervention in the form of explicitly linking to lib B. So --no-add-needed enforces the more correct behavior of explicitly linking against the libraries whose symbols you actually use. It's pretty obvious why distributions would be interested in using these two flags, since they can trim down dependencies to the really needed, making our lives a lot easier. In summary: changing the build system to link everything against -core per default and use --no-undefined should only help you keep everything explicit and clean. I can't think of any disadvantage, but maybe I'm overlooking something important. Maybe turn it on per default while the 2.1 series is still alpha, and see if some problem arises? > Either way, I'd be a lot more comfortable about a patch on the 2.1 > series than on 2.0. No problem. I'll keep the current dirty patch in the Debian 2.0 packages (because we need it anyway), and prepare a cleaner one for the 2.1 series. Cheers -- Leo "costela" Antunes [insert a witty retort here] _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://lists.monkey.org:8080/listinfo/libevent-users
