From: Andy Wingo <wingo@pobox.com>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Cc: bug-guile@gnu.org, bug-libtool@gnu.org
Subject: Re: documentation / behavior discrepancy with lt_dlopenext
Date: Thu, 31 Mar 2011 10:33:11 +0200 [thread overview]
Message-ID: <m3k4ffzo3c.fsf@unquote.localdomain> (raw)
In-Reply-To: <alpine.GSO.2.01.1103302025100.10593@freddy.simplesystems.org> (Bob Friesenhahn's message of "Wed, 30 Mar 2011 20:31:17 -0500 (CDT)")
On Thu 31 Mar 2011 03:31, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> writes:
> On Wed, 30 Mar 2011, Andy Wingo wrote:
>>
>> Sure, that's probably right. However it's tough to tell. You could
>> look for "\.so(\.|$)" or something. But that's encoding lots of
>> details.
>>
>> I think that uses of dlopenext are already oblivious to `stat' calls,
>> because they sanction looking for .la files before e.g. .so files, so
>> it's not a problem to just do what the doc says: bare path first, then
>> grovel extensions.
>
> Use of .la files does not incur more stat calls unless the .la file is
> not present. Using .la files is really a better solution than what you
> are trying to do.
That might well be true! (I don't know enough of the details.) However
on most systems that does not work for system libraries like libc. This
particular bug report came from a user who wanted to link against a
library without installing the -dev package on his OS, so he wouldn't
have .la files anyway. Not to mention distros that don't install .la
files, like Fedora et al.
Just to clarify the use case. I see we all agree the current behavior
is a bug :)
Cheers,
Andy
--
http://wingolog.org/
next prev parent reply other threads:[~2011-03-31 8:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-30 17:19 documentation / behavior discrepancy with lt_dlopenext Andy Wingo
2011-03-30 19:20 ` Ralf Wildenhues
2011-03-30 21:36 ` Andy Wingo
2011-03-31 1:31 ` Bob Friesenhahn
2011-03-31 8:33 ` Andy Wingo [this message]
2011-07-01 15:03 ` Andy Wingo
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
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3k4ffzo3c.fsf@unquote.localdomain \
--to=wingo@pobox.com \
--cc=bfriesen@simple.dallas.tx.us \
--cc=bug-guile@gnu.org \
--cc=bug-libtool@gnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).