Re: [autoconf] how do I avoid dynamic libraries?
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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 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 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 so that it never finds > libffcall's shared libraries even if they are mistakenly installed? > >  http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/README?root=libffcall > >  http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/configure.in?root=libffcall > >  http://clisp.hg.sourceforge.net/hgweb/clisp/clisp/file/tip/src/m4/ffcall.m4 > > _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
[GCC Help] [Kernel Discussion] [RPM Discussion] [Red Hat Development] [Yosemite News] [USB] [Samba]