Re: Interface range compatibility?

Answer (to stdout). Over time, the user could gain the habit of asking/answering those questions w/o the help of the program, but even if not, what are computers for, but to do these fiddly calculations for us? -- Thien-Thi Nguyen GPG key: 4C807502 (if you're human and you know it)

Re: old solaris problem

() Bob Friesenhahn () Thu, 17 Feb 2011 09:02:38 -0600 (CST) I recommend eliminating use of this macro. Whatever purpose it was intending to solve surely no longer exists. I use Solaris for development and have never needed anything similar to what this macro is doing. It seems like

old solaris problem

In the GNU Serveez configure.ac, i see: dnl dnl Check if libtool copes with SunOS/Solaris. GNU libtool 1.4.2 and less dnl fail to create self-contained shared libraries. This is due to the gcc dnl - native linker combination. The below macro adds the -liberty path dnl and -lgcc to the

Re: installing modules sans .la file and ugo-x

() Thien-Thi Nguyen <[EMAIL PROTECTED]> () Wed, 19 Mar 2008 09:55:06 +0100 I would like to install a "module" (ie, package-private shared-object library to be loaded by libltdl) sans the .la file and w/ perms -x. Sans .la because the package has other mechanisms for kee

installing modules sans .la file and ugo-x

I would like to install a "module" (ie, package-private shared-object library to be loaded by libltdl) sans the .la file and w/ perms -x. Sans .la because the package has other mechanisms for keeping track of modules (and their dependencies); the .la is superfluous. Perm -x mostly because i'm irra

Re: AC_PROG_LIBTOOL sets CFLAGS

() Peter O'Gorman <[EMAIL PROTECTED]> () Tue, 21 Aug 2007 14:57:55 -0500 AC_PROG_LIBTOOL calls AC_PROG_CC which sets default CFLAGS (but only if they are not already set). so what is the recommended way to get configure-generated flags into AM_CFLAGS, leaving CFLAGS empty? i see in many pl

AC_PROG_LIBTOOL sets CFLAGS

according to my reading of info nodes: (libtool) AC_PROG_LIBTOOL (automake) Flag Variables Ordering the shell variable CFLAGS should have no value after AC_PROG_LIBTOOL. i.e., i should expect the configure.ac fragment: echo "CFLAGS: $CFLAGS" AC_PROG_LIBTOOL echo "CFLAGS: $CFLAGS" to create

Re: RFC: proposal for indirect deplibs

Ralf Wildenhues <[EMAIL PROTECTED]> writes: [definitions] Does that make more sense? yes thanks, i find "base" and "derived" easier to understand. What exactly do you mean with these terms? (I have a vague idea but would rather like to know a precise definition.) in trying to be mo

Re: RFC: proposal for indirect deplibs

Ralf Wildenhues <[EMAIL PROTECTED]> writes: [definitions] my head is already swimming because "dependent", "dependency" and "dependence" all are very subtly different and have different meanings in different contexts. i like the term "upstream" and "downstream" because a moment's thought in c

Re: avoiding C++, Fortran tags

Matt Fago <[EMAIL PROTECTED]> writes: although I'm still not exactly sure where the "proper" place is to put the patch at a system-level. i see the original macro defined in /usr/local/share/aclocal/libtool.m4, so depending on the particular scanning order aclocal uses, you could try to pla

avoiding C++, Fortran tags

hello libtool folks, i recently swiched to libtool 1.5 and now AC_PROG_LIBTOOL pulls in a horrendous amount of irrelevant checks for C++ and Fortran. to work around this, i have resorted to doing: aclocal echo 'AC_DEFUN([_LT_AC_TAGCONFIG],[])' >> aclocal.m4 probably it's better to call it a

Re: OMVS port

drat, i was very excited, having misread the subject line as OVMS (openvms from dec now compaq now hp now confused... ;-). reality strikes again. thi ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: zonking .la and .a files

argh! it figures, the answer is actually in autoconf: AC_DISABLE_STATIC AM_PROG_LIBTOOL sorry for the noise. thi ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

zonking .la and .a files

greetings libtool and automake folks, is there any way to tell libtool/automake NOT to install .la and .a files? i would like to install only the shared object libraries as "plugin modules" (the main program knows of the plugin modules location and can dlopen them directly w/o search; there is no

Re: libtool "module" behavior and darwin

is this discussion informed by libtool preopen facilities? thi ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool

Re: Converting a project to libtool

Jeff Bailey <[EMAIL PROTECTED]> writes: I did that, and 0:0:3 gives me an "age is greater than current interface" error. probably the "-release" flag in libtool info node "Release numbers" is what you want. however, DWR: i think this option is somewhat frowned upon. thi ___

Re: lt_* stability

From: [EMAIL PROTECTED] Date: Tue, 28 May 2002 13:32:22 +0100 The core lt_dlinit/lt_dlopen/lt_dlsym/lt_dlclose/lt_dlexit API remains unchanged since its original introduction into libtool releases. New calls have been added to exploit richer semantics and new features over the

lt_* stability

hello, i'm interested in finding out how stable libltdl API is. has it changed much in its history? do the Authors think it will change much in its future? thanks for any insight into this. thi ___ Libtool mailing list [EMAIL PROTECTED] http://mail