64/0b9279bea124ba78e551cd28027e494ff45c5a

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 086BE40D166\r
   6         for <notmuch@notmuchmail.org>; Fri, 29 Oct 2010 14:37:27 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id OCr36AF9L+Hu; Fri, 29 Oct 2010 14:37:16 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 98EAD40D148;\r
  19         Fri, 29 Oct 2010 14:37:16 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 48E632540F4; Fri, 29 Oct 2010 14:37:16 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Felipe Contreras <felipe.contreras@gmail.com>, notmuch@notmuchmail.org\r
  24 Subject: Re: [PATCH 2/3] build: fix DSO dependencies\r
  25 In-Reply-To: <1275735915-22650-3-git-send-email-felipe.contreras@gmail.com>\r
  26 References: <1275735915-22650-1-git-send-email-felipe.contreras@gmail.com>\r
  27         <1275735915-22650-3-git-send-email-felipe.contreras@gmail.com>\r
  28 User-Agent: Notmuch/0.3.1-139-g14f1a79 (http://notmuchmail.org) Emacs/23.2.1\r
  29         (i486-pc-linux-gnu)\r
  30 Date: Fri, 29 Oct 2010 14:37:16 -0700\r
  31 Message-ID: <87pqus65pv.fsf@yoom.home.cworth.org>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: multipart/signed; boundary="=-=-=";\r
  34         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  35 X-BeenThere: notmuch@notmuchmail.org\r
  36 X-Mailman-Version: 2.1.13\r
  37 Precedence: list\r
  38 List-Id: "Use and development of the notmuch mail system."\r
  39         <notmuch.notmuchmail.org>\r
  40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  43 List-Post: <mailto:notmuch@notmuchmail.org>\r
  44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  47 X-List-Received-Date: Fri, 29 Oct 2010 21:37:27 -0000\r
  48 \r
  49 --=-=-=\r
  50 Content-Transfer-Encoding: quoted-printable\r
  51 \r
  52 On Sat,  5 Jun 2010 14:05:14 +0300, Felipe Contreras <felipe.contreras@gmai=\r
  53 l.com> wrote:\r
  54 > At least on Fedora 13, this doesn't link; the linker finds the\r
  55 > dependencies, and aborts saying we should include them.\r
  56 ...\r
  57 > We do need to link at least to what we really use, the linker resolves\r
  58 > the dependencies of our dependencies at loading time. So let's only\r
  59 > specify what we use directly.\r
  60 \r
  61 Hi Felipe,\r
  62 \r
  63 You're certainly right that the linking was bogus. The notmuch binary\r
  64 was only linking directly against libnotmuch (which in turned linked\r
  65 against GMime, Xapian, and talloc). But meanwhile, the notmuch binary\r
  66 is also directly using GMime and talloc so should be linking directly\r
  67 against those.\r
  68 \r
  69 > -ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)\r
  70 >  FINAL_NOTMUCH_LDFLAGS +=3D $(CONFIGURE_LDFLAGS)\r
  71 > -FINAL_NOTMUCH_LINKER =3D CXX\r
  72 > -endif\r
  73 \r
  74 But the change above causes the notmuch binary to also link directly\r
  75 against Xapian, (which the binary does not use directly), so that's\r
  76 undesired.\r
  77 \r
  78 > -     gmime_ldflags=3D$(pkg-config --libs $gmimepc)\r
  79 > +     if [ $linker_resolves_library_dependencies =3D "1" ]; then\r
  80 > +             gmime_ldflags=3D"-lgmime-2.6 -lgobject-2.0 -lglib-2.0"\r
  81 > +     else\r
  82 > +             gmime_ldflags=3D$(pkg-config --libs $gmimepc)\r
  83 > +     fi\r
  84 \r
  85 This part I don't understand. Why is it necessary to avoid using\r
  86 pkg-config in this case? That sounds to me like a maintenance\r
  87 nightmare. If the pkg-config information for GMime is wrong then we\r
  88 should get that fixed, and not workaround it.\r
  89 \r
  90 So, finally, I implemented a much more narrow fix for the linking\r
  91 problem, (simply adding $(GMIME_LDFLAGS) and $(TALLOC_LDFLAGS) to the\r
  92 FINAL_NOTMUCH_LDFLAGS assignement).\r
  93 \r
  94 I tested this by installing binutils-gold on my Debian system. This\r
  95 caused a compilation failure before my patch, but compilation succeeds\r
  96 after my patch. I'm optimistic that this means that a Fedora compilation\r
  97 will work as well now. Can you test that please?\r
  98 \r
  99 =2DCarl\r
 100 \r
 101 PS. For the other two patches you sent. I couldn't see that #1 (moving\r
 102 the platform-detection earlier in configure) is necessary. But #3 seems\r
 103 obviously correct, so I've pushed that now.\r
 104 \r
 105 I do apologize that it has been many months since you posted these\r
 106 patches, and that you got no review of them until now. But thanks indeed\r
 107 for sending them!\r
 108 \r
 109 =2D-=20\r
 110 carl.d.worth@intel.com\r
 111 \r
 112 --=-=-=\r
 113 Content-Type: application/pgp-signature\r
 114 \r
 115 -----BEGIN PGP SIGNATURE-----\r
 116 Version: GnuPG v1.4.10 (GNU/Linux)\r
 117 \r
 118 iD8DBQFMyz6M6JDdNq8qSWgRAhO+AJ4+dVg9YQlEhSsiFsNxOcl6Vy9VRQCgpEDB\r
 119 8+J4pJ2zyERTWeEuLIgfc0A=\r
 120 =pRPk\r
 121 -----END PGP SIGNATURE-----\r
 122 --=-=-=--\r