[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [autoconf] how do I avoid dynamic libraries?
From: |
suzuki toshiya |
Subject: |
Re: [autoconf] how do I avoid dynamic libraries? |
Date: |
Wed, 15 Feb 2012 02:33:18 +0900 |
User-agent: |
Mozilla-Thunderbird 2.0.0.12 (X11/20080406) |
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
>
>