Loading ...
Sorry, an error occurred while loading the content.
 

additional glib-related cleanup?

Expand Messages
  • Nathan Stratton Treadway
    While researching the glib-related build problems, I noticed that the Debian patch that resolves the g_thread_supported() bug also removes the g_thread_init()
    Message 1 of 4 , Jun 25, 2012
      While researching the glib-related build problems, I noticed that the
      Debian patch that resolves the g_thread_supported() bug also removes the
      g_thread_init() call later on in common-src/glib-util.c , with the
      following explanation "And g_thread_init() is just a dummy stub, so it's
      no use to call it."

      I personally don't know anything about these glib changes, but while I
      had the pages open on my screen I thought I'd forward these links on
      to you in case you thought it was worth making a similar change on the
      upstream side:
      http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667836
      http://git.gag.com/?p=debian/amanda;a=commitdiff;h=3c4bb201

      Nathan

      ----------------------------------------------------------------------------
      Nathan Stratton Treadway - nathanst@... - Mid-Atlantic region
      Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
      GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
      Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
    • Dustin J. Mitchell
      On Mon, Jun 25, 2012 at 5:42 PM, Nathan Stratton Treadway ... I think that s based on knowledge of what versions of glib are used in Debian, whereas Amanda
      Message 2 of 4 , Jun 25, 2012
        On Mon, Jun 25, 2012 at 5:42 PM, Nathan Stratton Treadway
        <nathanst@...> wrote:
        > While researching the glib-related build problems, I noticed that the
        > Debian patch that resolves the g_thread_supported() bug also removes the
        > g_thread_init() call later on in common-src/glib-util.c , with the
        > following explanation "And g_thread_init() is just a dummy stub, so it's
        > no use to call it."

        I think that's based on knowledge of what versions of glib are used in
        Debian, whereas Amanda maintains a pretty long tail of
        backward-compatibility with older versions of glib.

        Dustin
      • Nathan Stratton Treadway
        ... Well, I guess the point is that while on the one hand the Debian patch simply deletes both chunks of code, the Amanda patch instead does an #IF version
        Message 3 of 4 , Jun 25, 2012
          On Mon, Jun 25, 2012 at 17:59:03 -0500, Dustin J. Mitchell wrote:
          > On Mon, Jun 25, 2012 at 5:42 PM, Nathan Stratton Treadway
          > <nathanst@...> wrote:
          > > While researching the glib-related build problems, I noticed that the
          > > Debian patch that resolves the g_thread_supported() bug also removes the
          > > g_thread_init() call later on in common-src/glib-util.c , with the
          > > following explanation "And g_thread_init() is just a dummy stub, so it's
          > > no use to call it."
          >
          > I think that's based on knowledge of what versions of glib are used in
          > Debian, whereas Amanda maintains a pretty long tail of
          > backward-compatibility with older versions of glib.

          Well, I guess the point is that while on the one hand the Debian patch
          simply deletes both chunks of code, the Amanda patch instead does
          an #IF version check around the g_thread_supported() assertion, but
          doesn't touch the g_thread_init() block at all.

          Clearly you wouldn't take the Debian patch as-is, but I guess the
          question is whether it's worth adding a parallel version check to the
          g_thread_init() call, too, or something along those lines.

          Obviously not too big a deal (since the init() call doesn't hurt the
          functioning of the programs), but I wondered if there could be some
          advantage to treating the two blocks consistently....

          Nathan

          ----------------------------------------------------------------------------
          Nathan Stratton Treadway - nathanst@... - Mid-Atlantic region
          Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
          GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
          Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
        • Dustin J. Mitchell
          On Mon, Jun 25, 2012 at 7:06 PM, Nathan Stratton Treadway ... Honestly, for compatibility-sensitive things like this, it s often best to leave well enough
          Message 4 of 4 , Jun 25, 2012
            On Mon, Jun 25, 2012 at 7:06 PM, Nathan Stratton Treadway
            <nathanst@...> wrote:
            > Obviously not too big a deal (since the init() call doesn't hurt the
            > functioning of the programs), but I wondered if there could be some
            > advantage to treating the two blocks consistently....

            Honestly, for compatibility-sensitive things like this, it's often
            best to leave well enough alone. There may be some system or version
            of glib out there that would get missed in this cleanup.

            Dustin
          Your message has been successfully submitted and would be delivered to recipients shortly.