From: Carl Worth <cworth@cworth.org>
To: Felipe Contreras <felipe.contreras@gmail.com>, notmuch@notmuchmail.org
Subject: Re: [PATCH 2/3] build: fix DSO dependencies
In-Reply-To: <1275735915-22650-3-git-send-email-felipe.contreras@gmail.com>
References: <1275735915-22650-1-git-send-email-felipe.contreras@gmail.com>
	<1275735915-22650-3-git-send-email-felipe.contreras@gmail.com>
User-Agent: Notmuch/0.3.1-139-g14f1a79 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Fri, 29 Oct 2010 14:37:16 -0700
Message-ID: <87pqus65pv.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Sat,  5 Jun 2010 14:05:14 +0300, Felipe Contreras <felipe.contreras@gmai=
l.com> wrote:
> At least on Fedora 13, this doesn't link; the linker finds the
> dependencies, and aborts saying we should include them.
...
> We do need to link at least to what we really use, the linker resolves
> the dependencies of our dependencies at loading time. So let's only
> specify what we use directly.

Hi Felipe,

You're certainly right that the linking was bogus. The notmuch binary
was only linking directly against libnotmuch (which in turned linked
against GMime, Xapian, and talloc). But meanwhile, the notmuch binary
is also directly using GMime and talloc so should be linking directly
against those.

> -ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
>  FINAL_NOTMUCH_LDFLAGS +=3D $(CONFIGURE_LDFLAGS)
> -FINAL_NOTMUCH_LINKER =3D CXX
> -endif

But the change above causes the notmuch binary to also link directly
against Xapian, (which the binary does not use directly), so that's
undesired.

> -	gmime_ldflags=3D$(pkg-config --libs $gmimepc)
> +	if [ $linker_resolves_library_dependencies =3D "1" ]; then
> +		gmime_ldflags=3D"-lgmime-2.6 -lgobject-2.0 -lglib-2.0"
> +	else
> +		gmime_ldflags=3D$(pkg-config --libs $gmimepc)
> +	fi

This part I don't understand. Why is it necessary to avoid using
pkg-config in this case? That sounds to me like a maintenance
nightmare. If the pkg-config information for GMime is wrong then we
should get that fixed, and not workaround it.

So, finally, I implemented a much more narrow fix for the linking
problem, (simply adding $(GMIME_LDFLAGS) and $(TALLOC_LDFLAGS) to the
FINAL_NOTMUCH_LDFLAGS assignement).

I tested this by installing binutils-gold on my Debian system. This
caused a compilation failure before my patch, but compilation succeeds
after my patch. I'm optimistic that this means that a Fedora compilation
will work as well now. Can you test that please?

=2DCarl

PS. For the other two patches you sent. I couldn't see that #1 (moving
the platform-detection earlier in configure) is necessary. But #3 seems
obviously correct, so I've pushed that now.

I do apologize that it has been many months since you posted these
patches, and that you got no review of them until now. But thanks indeed
for sending them!

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFMyz6M6JDdNq8qSWgRAhO+AJ4+dVg9YQlEhSsiFsNxOcl6Vy9VRQCgpEDB
8+J4pJ2zyERTWeEuLIgfc0A=
=pRPk
-----END PGP SIGNATURE-----
--=-=-=--