Re: Linking one library against another + static vs. shared

2009, at 11:45, Ralf Wildenhues wrote: Hello Sander, * Sander Niemeijer wrote on Tue, Jul 21, 2009 at 05:35:52PM CEST: Suppose we have a library foo that is build with autoconf/automake/ libtool and gets installed. Now, the person who installed this package used (for whatever reason) a --disable

Re: Linking one library against another + static vs. shared

Hi Ralf, Thank you for answering my email. On 25 jul 2009, at 11:45, Ralf Wildenhues wrote: * Issue 1 When compiling libbar, libtool includes libfoo.a when linking the shared version of libbar, but for the static version of libbar the libfoo library is *not* included. This seems ok to me.

Linking one library against another + static vs. shared

ing the executable) that should, by investigating the libbar dependencies (either a libfoo.la or a libfoo.a reference), pick up the appropriate libfoo library (either static or shared, whichever is available/needed) and include it in the link line. Best regards, Sander Niemeijer _

Re: LT_* equivalent to AC_CHECK_LIB?

Here are some links to the archive that you might find interesting: My suggestion for a LT_AC_CHECK_SHLIB: http://lists.gnu.org/archive/html/libtool/2004-10/msg00222.html Mind that there is a difference between linking a library against a library and linking a library against an application. W

Re: Avoiding to install some static libs

On 16-mei-2006, at 16:06, Pierre Ossman wrote: Hi! I'd like to avoid installing some of the static libs built, but I can't figure out how. I have a package that contains both "normal" libraries, for which I'd like both dynamic and static to be installed, and some modules. I'd like to k

Re: TODO 2.x: Using libtool 2.0 in autoconf tests

* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST: I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372

TODO 2.x: Using libtool 2.0 in autoconf tests

I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html Best regards, Sander Niemeijer

Re: Writing tests using Libtool

I did this by writing my own variant of these macros. You might want to check out this thread: It also explains the upward compatibility problems with such an approach. Best regards, Sander On woensdag, feb 9, 2005, at 13:30 Europe

Re: Using libtool 2.0 in autoconf tests

Oversimplifying, but: In a configure script, you can spell `libtool -[options] [objects]' as `LT_CHECK_LIB([options], [objects])'. Maybe we need LT_LINK_IFELSE instead/as well. What I need is a replacement for the LT_AC_LINK_SHLIB_IFELSE macro in:

Re: Using libtool 2.0 in autoconf tests

Agreed. I think that there are a small number of circumstances where the early-build of libtool was genuinely useful, and I think we should be able to wrap each of those cases is a shipped macro that leverages the knowledge already probed for libtool without needing to actually have a libtool scri

Re: Using libtool 2.0 in autoconf tests

On maandag, nov 22, 2004, at 15:29 Europe/Amsterdam, Gary V. Vaughan wrote: Hallo Ralf, Ralf Wildenhues wrote: C'mon Gary, two questions: is it *possible* to provide the old behavior without too much pain? I can't think of a way to do it cleanly :-( But I have no objections in principle. How

Re: Using libtool 2.0 in autoconf tests

On maandag, nov 22, 2004, at 12:05 Europe/Amsterdam, Peter O'Gorman wrote: Ralf Wildenhues wrote: C'mon Gary, two questions: is it *possible* to provide the old behavior without too much pain? Would that destroy some cool abstraction or some really fundamental thing? Or are you just waiting fo

Re: Using libtool 2.0 in autoconf tests

The theory: It is my belief that an actual link should not be necessary to test for some characteristic. Libtool runs a whole lot of autoconf tests at configure time to decide how it is going to link when the results of those tests are added to the generated libtool script. Consequently, you sho

Using libtool 2.0 in autoconf tests

I would think it only logical that I would also be able to perform some autoconf tests with my compilation/linking tool. Best regards, Sander Niemeijer ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool 1.9f: generation of libtool script

On woensdag, okt 27, 2004, at 15:59 Europe/Amsterdam, Bob Friesenhahn wrote: On Wed, 27 Oct 2004, Sander Niemeijer wrote: So my question is, is there still a way for me to perform my autoconf test now that the libtool script creation step is moved? Is it maybe possible to create the libtool

libtool 1.9f: generation of libtool script

some combination of lt* variables that are available in the configure script to perform a compilation and link step? Best regards, Sander Niemeijer ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool

Re: Problem porting linux shared library to windows using cygwin and libtool

provide a set of .m files as wrappers. If you want to see an example of how we tackled this problem, you could have a look at our open source BEAT toolbox (downloadable from http://www.science-and-technology.nl/beat; pick the 2.0.0rc1 version). Best regards, Sander Niemeijer On maandag, dec 15

Re: libtool 1.5 tag woes (static/shared)

Bringing the discussion back to the list. Begin forwarded message: Hi Paolo, I think I start to understand it now. When I was writing my e-mail, the libtool mail archive site was also not reachable, but today it was working again, so I have been able to do some catching up. As you already stat

Re: libtool 1.5 tag woes (static/shared)

/archive/html/libtool/2003-08/msg8.html> Just my 2c. Best regards, Sander Niemeijer On maandag, nov 17, 2003, at 11:57 Europe/Amsterdam, Paolo Bonzini wrote: Why make enable_shared and enable_static specific to a tag? Wouldn't it be odd that you create shared libs for "C" pro

Re: Forcing shared libaries

Ralph Schleicher already provided a patch to libtool for such a feature, but I don't know the current status of this patch (whether it will be in the next libtool release or not; anyone???). Ralphs patch: A small summary explaining

Re: Installing in a staging area

From the Automake documentation: "Automake generates support for the DESTDIR variable in all install rules. DESTDIR is used during the make install step to relocate install objects into a staging area. Each object and path is prefixed with the value of DESTDIR before being copied into the ins

Re: Detecting availability of a shared libray

003, at 17:25 Europe/Amsterdam, Sander Niemeijer wrote: Hi all, I have a package that produces a shared/static library via libtool. However this package needs to make use of some external library for data import/export. Since my library has both a shared and a static version this external library also need

Re: Detecting availability of a shared libray

Is there really nobody who can help me further with this? Regards, Sander On vrijdag, sep 5, 2003, at 17:25 Europe/Amsterdam, Sander Niemeijer wrote: Hi all, I have a package that produces a shared/static library via libtool. However this package needs to make use of some external library for

Detecting availability of a shared libray

only available as a static version. So my question now is, does anybody know whether there is a way to explicitly test for the availability of the shared version of the external library? Regards, Sander Niemeijer ___ Libtool mailing list [EMAIL

Re: Building static-only or shared-only libraries on a per targetbasis

Hi, Maybe I can clarify the reasons behind this patch a bit more, and also hopefully give an answer to your question. Usually within a package you can have three situations for a library. 1) Only a static version is meaningful In case you also have libraries of type 3) in your package, you do n

Re: Building static-only or shared-only libraries on a per targetbasis

Hi Ralph, Thanks for providing the patch. I tested it with your libtool-demo and it worked fine for me. Regards, Sander On zondag, aug 3, 2003, at 23:26 Europe/Amsterdam, Ralph Schleicher wrote: Hi, over the last months, there were multiple discussions on the libtool mailing list about the ne

Problem running 'make check' with fort77 installed

OS X 10.2.6 autoconf: 2.57 automake: 1.7.6 libtool (installed version): 1.5 (1.1220 2003/04/05 19:32:58) libtool (cvs version, on which I performed the 'make check'): 1.5a (1.1243 2003/07/15 00:05:21) fort77: latest version as retrieved through fink Regards, Sander Niemeijer __

Re: Request for option to disable building of static library

Hi, Does anybody know whether such a -no-static option for the libtool link mode is feasable? Can this be implemented by just adding a -no-static option to libtool that sets the internal libtool variable 'build_old_libs' to 'no' or would such a feature require some more effort? Adding this feat

Request for option to disable building of static library

ion to libtool that sets the internal libtool variable 'build_old_libs' to 'no' or would such a feature require some more effort? Regards, Sander Niemeijer ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool