autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: checking for libraries that link but do not run


From: Ben Pfaff
Subject: Re: checking for libraries that link but do not run
Date: Mon, 05 Oct 2009 14:58:53 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Bob Friesenhahn <address@hidden> writes:

> On Mon, 5 Oct 2009, Ben Pfaff wrote:
>>
>> I'm not sure what "be prepared for dealing with the pitfalls"
>> amounts to.  Can you point to an example of a correct way to deal
>> with the pitfalls?  What does your package do to deal with them?
>
> The unfortunate solution is to do huge amount of configure script
> testing and analyze the possible library dependencies and how to
> become aware of them.  Library order is often important.  Recent Linux
> makes things much easier due good support for implicit shared library
> dependencies but this just makes it more likely that your configure
> script will only work properly on Linux and only if shared libraries
> are installed.  It becomes necessary to test configure on other OSs
> without the implicit dependency support.

I am well aware that link order is important for making sure that
programs link properly.  But I am talking about a case where
programs linked fine, without warnings or errors, and produced an
executable, but the executable could not run, because the dynamic
linker could not find the shared libraries at runtime.

> And then there are the OSs that don't run an executable before it has
> been formally blessed, or won't run a binary executable from a network
> share, run afoul of a virus checker, or where the mount options fail
> to allow execution.

Yes, those problems will prevent a program from linking but not
running.  Those are the sort that I would want to make
"configure" fail, because they will make the configuration
broken.  I believe that the macro that I suggested at the start
of this thread will do an adequate job of detecting these problem
as well the problem that I originally identified.

>> Gnulib uses AC_RUN_IFELSE in many places.  I suspect that most
>> programs that use Gnulib will fall afoul of these problems too.
>
> It seems unlikely that Gnulib is dependent on very many other
> libraries.  Once your program/library becomes dependent on over 60
> other libraries then you will know that you have arrived.

At that point, I am impressed that your program can work at all.
I have no desire to make my program depend on that many other
libraries.
-- 
Ben Pfaff 
http://benpfaff.org




reply via email to

[Prev in Thread] Current Thread [Next in Thread]