[Top][All Lists]

[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 (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) : $(OBJECTS)
        $(LIBTOOL_LINK) $(CC) -o -rpath $(libdir) $(OBJECTS)

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

See also

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.


Sam Steingold wrote:
> There is a problem with the libffcall (
> package (un)maintained by
> Bruno Haible, described in <>:
> -- 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[2] so that the shared
>    libraries are never built even if the user asks for them?
> 2. how do I modify the clisp's[3] so that it never finds
>    libffcall's shared libraries even if they are mistakenly installed?
> [1]*checkout*/ffcall/README?root=libffcall
> [2] 
> [3] 

reply via email to

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