1.1.2 is broken if you have closefrom()

[Alan DeKok]

Frank Cusack <fcusack at 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.