Re: [autoconf] how do I avoid dynamic libraries?

[suzuki toshiya]

I'm not a user of LISP, so my comment could be pointless...

1. it seems that libffcall is already using GNU Libtool,
   so adding "-static" flag to the option when la file is built
   would be the easiest way, like,

(current)
libavcall.la : $(OBJECTS)
        $(LIBTOOL_LINK) $(CC) -o libavcall.la -rpath $(libdir) $(OBJECTS)

(modified)
libavcall.la : $(OBJECTS)
        $(LIBTOOL_LINK) $(CC) -static -o libavcall.la -rpath $(libdir) 
$(OBJECTS)

See also http://sourceware.org/autobook/autobook/autobook_88.html

2. I don't have good idea. I think there is no portable flag making
a linker to ignore specific shared library as far as we use "-lxxx"
option. Thus, we should do such by "add the pathname of archive
library to LIBS flag, and do not use -lxxx option in it". It is not
so difficult if the users of libffcall can specify the prefix of
the directory of libffcall, like "--with-libffcall=/somewhere", but,
if the location of libffcall is unknown, searching it would not be
deterministic. It would be heuristic, aslike the conventional search
for X11 library/headers. Another headache is that we cannot distinguish
archive library and shared library by its extensions (e.g. IBM AIX uses
".a" for both library), and I don't have good idea to distinguish them
quickly and precisely.

Regards,
mpsuzuki

Sam Steingold wrote:
> There is a problem with the libffcall (http://www.gnu.org/software/libffcall/
> http://savannah.gnu.org/projects/libffcall) package (un)maintained by
> Bruno Haible, described in <https://bugs.launchpad.net/bugs/274951>:
> 
> -- libffcall should be built without shared libraries as explained in
>    its README[1] file (most of the code is in headers anyway &c)
> 
> -- when clisp is linked against libffcall's shared libraries it crashes
>    on self-test
> 
> So, I have two questions:
> 
> 1. how do I modify the libffcall's configure.in[2] so that the shared
>    libraries are never built even if the user asks for them?
> 
> 2. how do I modify the clisp's configure.in[3] so that it never finds
>    libffcall's shared libraries even if they are mistakenly installed?
> 
> [1] http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/README?root=libffcall
> 
> [2] 
> http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/configure.in?root=libffcall
> 
> [3] 
> http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/tip/src/m4/ffcall.m4
> 
>