Frank Cusack <fcusack@fcusack.com> wrote:

1. Can I just check this into the 1.1.0 branch and then upintegrate to HEAD (later)?

Ok. I'm not sure the fix is required for head, as that is already using a newer libtool, which should work. I'd like to see the diff, or have a description of it first, though. Working with libtool & autoconf is pretty insane.

It'll be easier that way for me. Also, in consideration of the increasing complexity here, I'd suggest closing off 1.1 at this point, except for security fixes if there are any before 1.2 is available. I don't see why 1.2 shouldn't start fresh from HEAD.

There are a few dumb things I'd like to fix in head (destroying listeners on HUP), before that happens. But yes, it's been *way* too long since 1.x and head diverged. Personally, I think we should call head 2.0, given the other changes.

2. What is libltdl/ltdl.c#1.37 about? Is there a bug that I can reproduce to see the problem?

1.37? It's only at 1.7. And that's bug #98. The libltdl retards would allocate a data structure, partially fill it in, and then RETURN IT to the caller if ltdl_open() didn't work. Since ltdl_open() is documented as returning PTR on success and NULL on fail, it would look like the dlopen succeeded. The code would then call ltdl_sym(), using the previous bullshit structure, and the retarded ltdl_sym() code would de-reference a NULL pointer. It doesn't need to check, apparently, because that field is supposed to be initialized if ltdl_open() worked.

3. CVS and branching is pitiful. CVS is also otherwise not very good. I suggest p4 (it's free for open source use), but barring that, svn.

Hmm... subversion doesn't do multiple repositories, and it requires everyting but the kitchen sink to build. I'm using perforce at work, and it's fine (if a little odd). For open source VCS's, I'd prefer mercurial. Alan DeKok.