[notmuch] Notmuch shared library

[Carl Worth]

On Thu, 01 Apr 2010 14:44:36 +0200, Michal Sojka  wrote:
> On Thu, 01 Apr 2010, Carl Worth wrote:
> > 1. Use rpath for the local notmuch, (and use chrpath to remove it at the
> >time of "make install").
> > 
> > 3. Create a static program locally, but install a shared version.
> > 
> > 4. Create a static program by default, and make distributions pass a
> >--shared option to get the shared version that they want.
> 
> I'd like to be able to run gdb easily on non-installed notmuch, so I'm
> fine with 1, 3 and 4.

I really like the idea of (1) but it might cause a dependency on
chrpath, which would be obnoxious. Otherwise, it would require linking
the final application twice.

But if we're going to link twice, we might as well just do that (3).

I now don't see any advantage of (4) over (3). It's easy to compile both
static and shared, so there's not much reason to be able to disable one
or the other.

So I've now made the default "make" create a static "notmuch" binary and
a shared "notmuch-shared" binary. Then, "make install" installs
"notmuch-shared" but renames it to "notmuch".

The other reason I really wanted something like this is to be able to
ensure that the test suite tests the locally-compiled library, (and not
some installed version that the dynamic linker finds).

-Carl (happy to stay away from the pain of wrapper scripts)
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] Notmuch shared library

[Michal Sojka]

On Thu, 01 Apr 2010, Carl Worth wrote:
> On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft  
> wrote:
> > also sprach Michal Sojka  [2010.04.01.1310 +0200]:
> > > this can be solved by the following patch, but I don't know how portable
> > > it is. You can see the efect of this by
> > 
> > Please avoid rpath. The better solution is probably to create
> > a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.
> 
> So now should actually list some of the ideas I had:
> 
> 1. Use rpath for the local notmuch, (and use chrpath to remove it at the
>time of "make install").
> 
> 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but
>then install the real program, (not very unlike what libtool does).
> 
> 3. Create a static program locally, but install a shared version.
> 
> 4. Create a static program by default, and make distributions pass a
>--shared option to get the shared version that they want.

I'd like to be able to run gdb easily on non-installed notmuch, so I'm
fine with 1, 3 and 4.

-Michal

[notmuch] Notmuch shared library

[martin f krafft]

also sprach martin f krafft  [2010.04.01.1324 +0200]:
> Please avoid rpath. The better solution is probably to create
> a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

E.g. http://wiki.debian.org/RpathIssue

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

a common mistake that people make
when trying to design something completely foolproof
was to underestimate the ingenuity of complete fools.
 -- douglas adams, "mostly harmless"

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 

[notmuch] Notmuch shared library

[martin f krafft]

also sprach Michal Sojka  [2010.04.01.1310 +0200]:
> this can be solved by the following patch, but I don't know how portable
> it is. You can see the efect of this by

Please avoid rpath. The better solution is probably to create
a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

when everything is coming your way, you're in the wrong lane.

spamtraps: madduck.bogus at madduck.net
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
URL: 

[notmuch] Notmuch shared library

[Michal Sojka]

On Thu, 01 Apr 2010, Carl Worth wrote:
> Finally, I'm a tiny bit annoyed that now after a fresh checkout of
> notmuch and "make" that one can't easily run ./notmuch without either
> installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
> ideas on how to simplify that, but I'm not sure if any are good or worth
> it.

Hi,

this can be solved by the following patch, but I don't know how portable
it is. You can see the efect of this by

$ objdump -x notmuch|grep RPATH

diff --git a/Makefile.local b/Makefile.local
index 32b8f4a..2a1b55d 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -20,7 +20,7 @@ extra_cxxflags :=
 # Smash together user's values with our extra values
 FINAL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags)
 FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) 
$(extra_cflags) $(extra_cxxflags)
-FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS)
+FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) -Wl,-rpath,\$$ORIGIN/lib -z 
origin --enable-new-dtags

 all: notmuch notmuch.1.gz
 ifeq ($(MAKECMDGOALS),)

--Michal

[notmuch] Notmuch shared library

[Sebastian Spaeth]

On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth  wrote:
> Finally, I'm a tiny bit annoyed that now after a fresh checkout of
> notmuch and "make" that one can't easily run ./notmuch without either
> installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
> ideas on how to simplify that, but I'm not sure if any are good or worth
> it.

That was admittedly a very nice feature. And as I have proposed (but not
send any patch :-)). I would argue that a --shared and a --static option
(or whatever configure standard policy is for that) would make sense
that links notmuch either dynamically or statically.

But thanks for doing this work. Much appreciated
Sebastian

[notmuch] Notmuch shared library

[Carl Worth]

On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft  
wrote:
> also sprach Michal Sojka  [2010.04.01.1310 +0200]:
> > this can be solved by the following patch, but I don't know how portable
> > it is. You can see the efect of this by
> 
> Please avoid rpath. The better solution is probably to create
> a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

So now should actually list some of the ideas I had:

1. Use rpath for the local notmuch, (and use chrpath to remove it at the
   time of "make install").

2. Create a little shell script that calls LD_LIBRARY_PATH locally, but
   then install the real program, (not very unlike what libtool does).

3. Create a static program locally, but install a shared version.

4. Create a static program by default, and make distributions pass a
   --shared option to get the shared version that they want.

I can see advantages and disadvantages to each approach.

-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

[notmuch] Notmuch shared library

[Carl Worth]

On Fri, 12 Mar 2010 14:47:33 +0100, Ingmar Vanhassel  
wrote:
> I'd very much like to see this upstream.

Me too. ;-) Sorry for the long delay.

> I amended your first patch to make it install the notmuch.h header
> too.

A very nice addition.

> The second patch fixed some parallel make issue I had while testing
> your series.

As is this. I ran into this problem immediately when testing the first
patch.

> The third patch adds a configure switch to configure where to install
> libraries. It has one issue I'm aware off. Setting --prefix=/usr
> without setting --libdir does the wrong thing. This should probably be
> fixed, but I don't have any immediate ideas how to do this.

This configure option is nice too, but the problem you pointed out was
serious, (so, thanks for noting it). I went ahead and fixed this.

I also spent some time making sure I (think I) understand how library
sonames and library versions work. I did several investigations with
libtool that convinced me it adds problems without any tangible benefit,
(at least for the target platforms I'm aware of people using with
notmuch).

I finished this by establishing a 3-part library interface version,
(initially 1.0.0), along with careful documentation in the Makefile on
how to increment it. And of course, I ended up touching up about a
half-dozen issues in the Makefiles along the way.

We'll still want to add functions/macros to the library to make the
library version available to the user. And I do want to still add some
symbol hiding and potentially some symbol versioning to the library. But
I'm not making the patch series block on that.

Finally, I'm a tiny bit annoyed that now after a fresh checkout of
notmuch and "make" that one can't easily run ./notmuch without either
installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
ideas on how to simplify that, but I'm not sure if any are good or worth
it.

Anyway, this patch series is now pushed with my changes on top. Thanks,
Ben and Ingmar!

-Carl



-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 

Re: [notmuch] Notmuch shared library

[Carl Worth]

On Fri, 12 Mar 2010 14:47:33 +0100, Ingmar Vanhassel ing...@exherbo.org wrote:
 I'd very much like to see this upstream.

Me too. ;-) Sorry for the long delay.

 I amended your first patch to make it install the notmuch.h header
 too.

A very nice addition.

 The second patch fixed some parallel make issue I had while testing
 your series.

As is this. I ran into this problem immediately when testing the first
patch.

 The third patch adds a configure switch to configure where to install
 libraries. It has one issue I'm aware off. Setting --prefix=/usr
 without setting --libdir does the wrong thing. This should probably be
 fixed, but I don't have any immediate ideas how to do this.

This configure option is nice too, but the problem you pointed out was
serious, (so, thanks for noting it). I went ahead and fixed this.

I also spent some time making sure I (think I) understand how library
sonames and library versions work. I did several investigations with
libtool that convinced me it adds problems without any tangible benefit,
(at least for the target platforms I'm aware of people using with
notmuch).

I finished this by establishing a 3-part library interface version,
(initially 1.0.0), along with careful documentation in the Makefile on
how to increment it. And of course, I ended up touching up about a
half-dozen issues in the Makefiles along the way.

We'll still want to add functions/macros to the library to make the
library version available to the user. And I do want to still add some
symbol hiding and potentially some symbol versioning to the library. But
I'm not making the patch series block on that.

Finally, I'm a tiny bit annoyed that now after a fresh checkout of
notmuch and make that one can't easily run ./notmuch without either
installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
ideas on how to simplify that, but I'm not sure if any are good or worth
it.

Anyway, this patch series is now pushed with my changes on top. Thanks,
Ben and Ingmar!

-Carl





pgpycothoiRjz.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[Sebastian Spaeth]

On Thu, 01 Apr 2010 00:54:16 -0700, Carl Worth cwo...@cworth.org wrote:
 Finally, I'm a tiny bit annoyed that now after a fresh checkout of
 notmuch and make that one can't easily run ./notmuch without either
 installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
 ideas on how to simplify that, but I'm not sure if any are good or worth
 it.

That was admittedly a very nice feature. And as I have proposed (but not
send any patch :-)). I would argue that a --shared and a --static option
(or whatever configure standard policy is for that) would make sense
that links notmuch either dynamically or statically.

But thanks for doing this work. Much appreciated
Sebastian
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[Michal Sojka]

On Thu, 01 Apr 2010, Carl Worth wrote:
 Finally, I'm a tiny bit annoyed that now after a fresh checkout of
 notmuch and make that one can't easily run ./notmuch without either
 installing the library (or fiddling with LD_LIBRARY_PATH). I've got some
 ideas on how to simplify that, but I'm not sure if any are good or worth
 it.

Hi,

this can be solved by the following patch, but I don't know how portable
it is. You can see the efect of this by

$ objdump -x notmuch|grep RPATH

diff --git a/Makefile.local b/Makefile.local
index 32b8f4a..2a1b55d 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -20,7 +20,7 @@ extra_cxxflags :=
 # Smash together user's values with our extra values
 FINAL_CFLAGS = $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags)
 FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) 
$(extra_cflags) $(extra_cxxflags)
-FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS)
+FINAL_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) -Wl,-rpath,\$$ORIGIN/lib -z 
origin --enable-new-dtags
 
 all: notmuch notmuch.1.gz
 ifeq ($(MAKECMDGOALS),)

--Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[martin f krafft]

also sprach Michal Sojka sojk...@fel.cvut.cz [2010.04.01.1310 +0200]:
 this can be solved by the following patch, but I don't know how portable
 it is. You can see the efect of this by

Please avoid rpath. The better solution is probably to create
a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
when everything is coming your way, you're in the wrong lane.
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[martin f krafft]

also sprach martin f krafft madd...@madduck.net [2010.04.01.1324 +0200]:
 Please avoid rpath. The better solution is probably to create
 a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

E.g. http://wiki.debian.org/RpathIssue

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a common mistake that people make
when trying to design something completely foolproof
was to underestimate the ingenuity of complete fools.
 -- douglas adams, mostly harmless
 
spamtraps: madduck.bo...@madduck.net


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[Carl Worth]

On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft madd...@madduck.net wrote:
 also sprach Michal Sojka sojk...@fel.cvut.cz [2010.04.01.1310 +0200]:
  this can be solved by the following patch, but I don't know how portable
  it is. You can see the efect of this by
 
 Please avoid rpath. The better solution is probably to create
 a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.

So now should actually list some of the ideas I had:

1. Use rpath for the local notmuch, (and use chrpath to remove it at the
   time of make install).

2. Create a little shell script that calls LD_LIBRARY_PATH locally, but
   then install the real program, (not very unlike what libtool does).

3. Create a static program locally, but install a shared version.

4. Create a static program by default, and make distributions pass a
   --shared option to get the shared version that they want.

I can see advantages and disadvantages to each approach.

-Carl


pgpthvMYttzPV.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[Michal Sojka]

On Thu, 01 Apr 2010, Carl Worth wrote:
 On Thu, 1 Apr 2010 13:24:22 +0200, martin f krafft madd...@madduck.net 
 wrote:
  also sprach Michal Sojka sojk...@fel.cvut.cz [2010.04.01.1310 +0200]:
   this can be solved by the following patch, but I don't know how portable
   it is. You can see the efect of this by
  
  Please avoid rpath. The better solution is probably to create
  a wrapper for notmuch, which prepends to LD_LIBRARY_PATH.
 
 So now should actually list some of the ideas I had:
 
 1. Use rpath for the local notmuch, (and use chrpath to remove it at the
time of make install).
 
 2. Create a little shell script that calls LD_LIBRARY_PATH locally, but
then install the real program, (not very unlike what libtool does).
 
 3. Create a static program locally, but install a shared version.
 
 4. Create a static program by default, and make distributions pass a
--shared option to get the shared version that they want.

I'd like to be able to run gdb easily on non-installed notmuch, so I'm
fine with 1, 3 and 4.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] Notmuch shared library

[Carl Worth]

On Thu, 01 Apr 2010 14:44:36 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Thu, 01 Apr 2010, Carl Worth wrote:
  1. Use rpath for the local notmuch, (and use chrpath to remove it at the
 time of make install).
  
  3. Create a static program locally, but install a shared version.
  
  4. Create a static program by default, and make distributions pass a
 --shared option to get the shared version that they want.
 
 I'd like to be able to run gdb easily on non-installed notmuch, so I'm
 fine with 1, 3 and 4.

I really like the idea of (1) but it might cause a dependency on
chrpath, which would be obnoxious. Otherwise, it would require linking
the final application twice.

But if we're going to link twice, we might as well just do that (3).

I now don't see any advantage of (4) over (3). It's easy to compile both
static and shared, so there's not much reason to be able to disable one
or the other.

So I've now made the default make create a static notmuch binary and
a shared notmuch-shared binary. Then, make install installs
notmuch-shared but renames it to notmuch.

The other reason I really wanted something like this is to be able to
ensure that the test suite tests the locally-compiled library, (and not
some installed version that the dynamic linker finds).

-Carl (happy to stay away from the pain of wrapper scripts)


pgpeo8OEpElXY.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[notmuch] Notmuch shared library

[Ben Gamari]

Hey all,

Here's a rebased version of my shared library patch. It's pretty similar to the
last version and should build against a clean tree (I'd recommend git clean 
-fxd).
Let me know if you have any build issues.

In the eyes of the powers that be, what is the long-term status of this patch?
It's been pretty painless to rebase, but it would be nice to merge at some
point. Then perhaps we could focus a bit on the bindings situation. Just a
thought.

Cheers,

- Ben

[notmuch] Notmuch shared library

[Ben Gamari]

Hey all,

Here's a rebased version of my shared library patch. It's pretty similar to the
last version and should build against a clean tree (I'd recommend git clean 
-fxd).
Let me know if you have any build issues.

In the eyes of the powers that be, what is the long-term status of this patch?
It's been pretty painless to rebase, but it would be nice to merge at some
point. Then perhaps we could focus a bit on the bindings situation. Just a
thought.

Cheers,

- Ben

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch