On Fri, Jun 17, 2011 at 12:11 PM, Leo 'costela' Antunes
<cost...@debian.org> wrote:
> On 17/06/11 17:42, Nick Mathewson wrote:
>> * AGE: With how many previous versions of the ABI is "Current"
>> version backward-compatible? This increments whenever the ABI changes
>> in a backward compatible way, and
>
> aaaah, that's the catch I merrily overlooked!
>
>> According to the libtool source, different shared-library systems
>> build their version numbers in different ways. Linux does
>> "{Current-age}.age.revision"; freebsd does "current.revision"; Irix
>> gets downright weird, and so on.
>>
>> So yeah; nothing to worry about here. :)
>
> Indeed, makes all the sense in the world now.
>
> 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.
The main reason for doing it in windows only is that it is
(supposedly? apparently?) necessary to get any kind of working DLLs
out of gcc on windows. (I'm not sure that whether it's *absolutely*
needed there, or whether it's just "only needed so long as you don't
explicitly list all of your DLL imports and exports.") Until your
mail, I wasn't actually aware that the option did anything useful on
non-windows platforms. :)
> 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?
Either way, I'd be a lot more comfortable about a patch on the 2.1
series than on 2.0.
yrs,
--
Nick
_______________________________________________
Libevent-users mailing list
Libevent-users@monkey.org
http://lists.monkey.org:8080/listinfo/libevent-users
