From: Jeff Garzik <jeff@garzik.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Project Hail List <hail-devel@vger.kernel.org>
Subject: Re: [Patch 1/1] CLD: fix crash in __mutex_get_max (libdb-4.7.so) on F13
Date: Wed, 02 Dec 2009 05:40:25 -0500 [thread overview]
Message-ID: <4B164419.3060507@garzik.org> (raw)
In-Reply-To: <20091201181812.15a28bd2@redhat.com>
On 12/01/2009 08:18 PM, Pete Zaitcev wrote:
> On Sun, 29 Nov 2009 20:38:45 -0500
> Jeff Garzik<jeff@garzik.org> wrote:
>
>> Interesting... I recall the root cause clearly, now: /usr/include/db.h
>> always refers to the latest installed db4, even if compat-db{,45,46} is
>> installed. Our configure recipe links with the most recent db4 listed
>> in configure.ac, combined with the installed /usr/include/db.h. Thus,
>> each new db4 version produces a mismatch.
>
> I solicited suggestions on a blog, and someone asked why we don't
> use db without specific version. I assumed we do it so we don't
> get linked with something ancient like db3. Is that so? If yes,
> how about something like this:
libdb does not exist anywhere but more recent versions of Linux. That
link does not exist on older, non-RHL Linux's, nor on FreeBSD, nor on
Solaris. The proposed configure change would actually make us much
-less- portable, unfortunately.
The ideal is somewhat close to what a LJ poster proposed:
* include from $include_dir/$db_version
* link from libdb-$db_version
* provide pkgconfig info that gives us precise location information
That's how, eg. glib/gtk+ 1.x can co-exist with glib/gtk+ 2.x.
But we lack a time machine to make this happen :/
Jeff
next prev parent reply other threads:[~2009-12-02 10:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-30 1:17 [Patch 1/1] CLD: fix crash in __mutex_get_max (libdb-4.7.so) on F13 Pete Zaitcev
2009-11-30 1:38 ` Jeff Garzik
2009-11-30 2:05 ` Pete Zaitcev
2009-12-02 1:18 ` Pete Zaitcev
2009-12-02 10:40 ` Jeff Garzik [this message]
2009-11-30 13:34 ` Jeff Garzik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B164419.3060507@garzik.org \
--to=jeff@garzik.org \
--cc=hail-devel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.