DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=LaiGQ5TFiRkO72QSpC7C+Yj31p27/KMtKXduKRjcdlscFviBplj/leVEUnJbPSLChs
	uGucvHFy93i3fh/MsnXSbWTGvhdb+yJqL3Wu0fEoPxps3TPR+KdKaKY+TB+4vZp15qPG
	nMUgPd34+0VTJMKYkLPy1RtG2DdJ4IHb/279A=
MIME-Version: 1.0
In-Reply-To: <87pqus65pv.fsf@yoom.home.cworth.org>
References: <1275735915-22650-1-git-send-email-felipe.contreras@gmail.com>
	<1275735915-22650-3-git-send-email-felipe.contreras@gmail.com>
	<87pqus65pv.fsf@yoom.home.cworth.org>
Date: Sat, 30 Oct 2010 02:17:18 +0300
Message-ID: <AANLkTi=iMwf7tMs6C7EFb7ZMhHFfXsZvqA2SovUOsGZW@mail.gmail.com>
Subject: Re: [PATCH 2/3] build: fix DSO dependencies
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Carl Worth <cworth@cworth.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org
Precedence: list

Hello,

On Sat, Oct 30, 2010 at 12:37 AM, Carl Worth <cworth@cworth.org> wrote:
> On Sat, =C2=A05 Jun 2010 14:05:14 +0300, Felipe Contreras <felipe.contrer=
as@gmail.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.
>
> 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)
>> =C2=A0FINAL_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.

Yes, I wanted to fix that in subsequent patches, but my first
objective was to get it to build.

>> - =C2=A0 =C2=A0 gmime_ldflags=3D$(pkg-config --libs $gmimepc)
>> + =C2=A0 =C2=A0 if [ $linker_resolves_library_dependencies =3D "1" ]; th=
en
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 gmime_ldflags=3D"-lgmime-2.6=
 -lgobject-2.0 -lglib-2.0"
>> + =C2=A0 =C2=A0 else
>> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 gmime_ldflags=3D$(pkg-config=
 --libs $gmimepc)
>> + =C2=A0 =C2=A0 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.

Well, it's not possible: pkg-config is supposed to work on win32 and
osx, so all the dependencies must be there, so:

% pkg-config --libs gmime-2.6
-pthread -lgmime-2.6 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0
-lgthread-2.0 -lrt -lglib-2.0

Means we would be linking to many libraries we are not going to use directl=
y.

Fortunately, I found the solution after writing that patch:
-Wl,--as-needed. With this the linker would automatically figure out
that we actually want to link only to -lgmime-2.6 -lgobject-2.0
-lglib-2.0.

> 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?

Patch #1 is not needed if gmime_ldflags in patch #2 are not changed
conditionally, which can be achieved by --as-needed.

I just sent my proposed updated patches.

--=20
Felipe Contreras