fix for link pthread-related link failure on Debian

fix for link pthread-related link failure on Debian

[Jim Meyering]

FYI, I've just fixed in LVM the problem I fixed in device-mapper
not long ago: link failure (due to unsatisfied -lpthread references)
when building with --enable-static_link.  I noticed it on a Debian
unstable system.  The patch will show up here in a few minutes:

  http://git.et.redhat.com/?p=lvm2.git

fix for link pthread-related link failure on Debian

[Dave Wysochanski]

On Wed, 2007-09-12 at 18:57 +0200, Jim Meyering wrote:
> FYI, I've just fixed in LVM the problem I fixed in device-mapper
> not long ago: link failure (due to unsatisfied -lpthread references)
> when building with --enable-static_link.  I noticed it on a Debian
> unstable system.  The patch will show up here in a few minutes:
> 
>   http://git.et.redhat.com/?p=lvm2.git
> 

This causes a build script I have to fail on my rhel4u5/6 xen node.
Might be a problem in my script but I've been using it successfully for
quite a while.

Will ping you offline.  

fix for link pthread-related link failure on Debian

[Jim Meyering]

Dave Wysochanski <dwysocha@redhat.com> wrote:

> On Wed, 2007-09-12 at 18:57 +0200, Jim Meyering wrote:
>> FYI, I've just fixed in LVM the problem I fixed in device-mapper
>> not long ago: link failure (due to unsatisfied -lpthread references)
>> when building with --enable-static_link.  I noticed it on a Debian
>> unstable system.  The patch will show up here in a few minutes:
>>
>>   http://git.et.redhat.com/?p=lvm2.git
>>
>
> This causes a build script I have to fail on my rhel4u5/6 xen node.
> Might be a problem in my script but I've been using it successfully for
> quite a while.

Thanks for the heads-up.
The generated configure script had vestiges of an upcoming
patch (which works fine in my polluted work area, btw, but
nowhere else), and since there is no rule to regenerate configure
when configure.in is newer, I mistakenly checked in the stale copy.

I've just rerun autoconf and committed the new, regenerated file.
This is one of the reasons I really like to have complete and
accurate dependencies.  Does anyone know why we lack this particular one?

Would anyone object to my adding the missing rule?

fix for link pthread-related link failure on Debian

[Alasdair G Kergon]

On Wed, Sep 12, 2007 at 08:29:25PM +0200, Jim Meyering wrote:
> I've just rerun autoconf and committed the new, regenerated file.
> This is one of the reasons I really like to have complete and
> accurate dependencies.  Does anyone know why we lack this particular one?

Because we ship the 'configure' file etc. and that is all that we
support in build environments: autoconf etc. should not be a requirement
to build the code.

> Would anyone object to my adding the missing rule?

Only if not done in such a way that it was optional and disabled by
default in build environments (though a non-fatal warning message would
be OK).

E.g. configure --enable-autoreconf would require the autoconf tools to
be present and then cause the makefiles to detect when they are
out-of-date and attempt to reconfigure themselves and relaunch etc.

Alasdair
-- 
agk at redhat.com

fix for link pthread-related link failure on Debian

[Jim Meyering]

Alasdair G Kergon <agk@redhat.com> wrote:
> On Wed, Sep 12, 2007 at 08:29:25PM +0200, Jim Meyering wrote:
>> I've just rerun autoconf and committed the new, regenerated file.
>> This is one of the reasons I really like to have complete and
>> accurate dependencies.  Does anyone know why we lack this particular one?
>
> Because we ship the 'configure' file etc. and that is all that we
> support in build environments: autoconf etc. should not be a requirement
> to build the code.
>
>> Would anyone object to my adding the missing rule?
>
> Only if not done in such a way that it was optional and disabled by
> default in build environments (though a non-fatal warning message would
> be OK).

How about making it so autoconf is required, only if you modify
configure.in or otherwise fiddle with mtimes to make it look like
configure is out of date?

> E.g. configure --enable-autoreconf would require the autoconf tools to
> be present and then cause the makefiles to detect when they are
> out-of-date and attempt to reconfigure themselves and relaunch etc.

Why cater to developers who lack the required version of autoconf?
Anyone clueful enough to build from source also knows enough to install
autoconf if they don't have it already.  As long as the requirement is
documented, no one can complain.  Heck, I'll even provide a script to
download/check-sig/build/install autoconf into a private directory.
I did that for another project (qpid) that also required automake
and libtool.

fix for link pthread-related link failure on Debian

[Alasdair G Kergon]

On Mon, Sep 17, 2007 at 08:15:23PM +0200, Jim Meyering wrote:
> How about making it so autoconf is required, only if you modify
> configure.in or otherwise fiddle with mtimes to make it look like
> configure is out of date?
 
I still think that is too much risk for the build environment.
A warning message, yes, but blocking the build, no.
I don't want any chance of autoconf running unless people specifically
ask for it.

> Why cater to developers who lack the required version of autoconf?

It's the build/packaging environment I consider primary here.  I do not
want builds from tarball to acquire an autoconf dependency, and if
there's a rule saying that 'configure' sometimes needs rebuilding
automatically then that dependency exists - even if you consider
the possibility only theoretical, timestamps may get messed up under
some configurations.

Another way to do this would be to flip the --enable-autoreconf default
setting in the release tarballs.  (E.g. Only attempt the autoreconf if
the version ends in -cvs.)

Alasdair
-- 
agk at redhat.com