Re: Running into cross-compilation issues with libtool (and autoconf) with libusb-0.1.12

On 13:19 Fri 30 Oct , Philip A. Prindeville wrote: The problem is that this is an early linkage on the build host, where the eventual DESTDIR hasn't yet been specified, but the resultant libusbpp.la ends up looking like: I suspect that you have two libtool libraries in the same source

Re: Issue with libtool when cross-compiling

using 'make install' and to copy the files from .libs manually :( -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: [sr #107416] relink with a DESTDIR install mistakenly links against old installed libraries rather than those in DESTDIR

the build system's C library. This turned out to be very tricky, because the library was perfectly fine at every step _except_ for 'make install', which was taking a perfectly fine library and writing a totally broken library to the install location. -- Nick Bowler, Elliptic Technologies (http

Re: Link Time Optimization

from the list. For example, I use the following procmail recipe: :0 * ^X-BeenThere:.*libt...@gnu.org libtool/ which puts all the mails from this list into the 'libtool' mailbox. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com

Re: How does one specify linking to 64 bit libraries when there is a choice?

into their binaries. -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ http://lists.gnu.org/mailman/listinfo/libtool

Re: inter-library-dependency, how?

, so that, whenever the library is linked into a program, libdir will be added to its run-time path. So it seems that adding -R/opt/packages/papi/4.1.2.1/lib to libfoo_la_LDFLAGS would do the trick? Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com

Re: ltdl and C++

of course it's not a dynamic executable. The actual binary that gets installed is located in .libs/. If you want to run ldd on an uninstalled executable, do it through libtool: libtool --mode=execute ldd hello Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com

Re: how do I avoid dynamic libraries?

] 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 Hope that helps, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com

Re: conditionally disabling libltdl subconfigure

in the grand scheme of things (especially compared to subproject!). You can then use Automake conditionals to control whether or not libltdl will be built. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https

Re: conditionally disabling libltdl subconfigure

On 2012-08-22 20:26 +0200, Brice Goglin wrote: Le 22/08/2012 19:44, Nick Bowler a écrit : On 2012-08-22 18:32 +0200, Brice Goglin wrote: Le 22/08/2012 16:32, Nick Bowler a écrit : [...] Other than adding -I$(top_builddir) to CPPFLAGS, as a workaround you could probably add something like

Re: Setting ACLOCAL_AMFLAGS with ':=' vs '='

in the future just because POSIX standardized ::= syntax. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: how to make libtool link with static system libraries instead of dynamic

static archives into shared libraries. The object files are usually incompatible. Nevertheless, you should be able to force the issue by directly listing archive filename(s) in _LIBADD, instead of using the -l option. Regards, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com

Re: GNU libtool-2.4.6 released [stable]

. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: Running an uninstalled executable

/libraries option. There should be no need to set LD_LIBRARY_PATH, although it can work in a pinch. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) ___ https://lists.gnu.org/mailman/listinfo/libtool

Re: Re[2]: MSW DLLs support in libtool

On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <nbow...@draconx.ca> wrote: > NB> Here's the thing. Libtool is, by default, designed to transparently > NB> support the case where building a shared library is not

Re: Re[4]: MSW DLLs support in libtool

On 2/10/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler <nbow...@draconx.ca> wrote: > NB> On 2/9/16, Vadim Zeitlin <vz-libt...@zeitlins.org> wrote: > NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler <

Re: MSW DLLs support in libtool

On 2/10/16, Bob Friesenhahn wrote: > On Wed, 10 Feb 2016, Peter Rosin wrote: >> I agree wholeheartedly with the notion that --disable-static should end >> up in a failure and not somehow degrade to a static build anyway. I > > Is this not the case? I have seen

Re: MSW DLLs support in libtool

On 2/10/16, Peter Rosin wrote: > Personally, I don't get why the win32 option exist at all. I see no > reason to discriminate against Windows like that. Make the no-windows- > purists opt out with no-win32 (or whatever) instead. What does the win32-dll option actually do?

Re: Re[2]: MSW DLLs support in libtool

On 2/10/16, Vadim Zeitlin <va...@zeitlins.org> wrote: > On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler <nbow...@draconx.ca> wrote: > NB> On 2/10/16, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote: > NB> > On Wed, 10 Feb 2016, Peter Rosin wrote: > NB>

Re: MSW DLLs support in libtool

On 2/12/16, Evgeny Grin <k...@yandex.ru> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 12.02.2016 0:14, Nick Bowler wrote: >> On 2/11/16, Evgeny Grin <k...@yandex.ru> wrote: >>> * change default shared lib mode from "on" to

Re: MSW DLLs support in libtool

On 2/9/16, Vadim Zeitlin wrote: > I'd like to create Windows binaries for my software from Linux, which > includes creating a couple of DLLs and EXEs that use them. This is not too > difficult to do with just manual makefiles as both the cross-compiler and > linker work

Re: MSW DLLs support in libtool

On 2/11/16, Evgeny Grin wrote: > * change default shared lib mode from "on" to "auto" or "try" and fail > if shared lib cannot be created when mode is "on". With that logic > "make" will do what requested instead of guessing that "something may be > useful even if not requested".

Re: Developing against $HOME/lib libraries and LD_LIBRARY_PATH

On 11/16/17, Paul "LeoNerd" Evans wrote: > I'm developing two different C libraries; lets just call them A and B. > A is fairly standalone, and B depends on A. [...] > But now suppose I have a possible change I want to make that needs > edits in both libraries. I don't

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 2020-01-08, Martin Liška wrote: > On 1/7/20 10:40 PM, Nick Bowler wrote: >> Regardless, $global_symbol_pipe is part of the documented libtool >> interface, which says you can do: >> >>eval "$NM progname | $global_symbol_pipe" >> >> This is o

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 1/7/20, Martin Liška wrote: > nm -B detection fails to be detected with -flto and -fno-common CFLAGS: > > configure:6307: checking command to parse /usr/bin/nm -B output from gcc > object [...] > configure:6536: gcc -o conftest -O2 -Wall -D_FORTIFY_SOURCE=2 > -fstack-protector-strong

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 1/7/20, Bob Friesenhahn wrote: > On Tue, 7 Jan 2020, Nick Bowler wrote: > >> On 1/7/20, Martin Liška wrote: >>> nm -B detection fails to be detected with -flto and -fno-common CFLAGS: > > I don't know what vintage this documentation is (the copyright says it

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 2020-01-07, Nick Bowler wrote: >>> I'm not 100% sure which libtool features will be affected by this >>> configuration failure. It doesn't fatally stop the configure script. >>> Probably dlpreopen won't work at all? >> >> Are there many users of dlp

Re: checking command to parse /usr/bin/nm -B output from gcc object... failed

On 2020-01-07, Nick Bowler wrote: > On 1/7/20, Martin Liška wrote: >> nm -B detection fails to be detected with -flto and -fno-common CFLAGS: >> >> configure:6307: checking command to parse /usr/bin/nm -B output from gcc >> object > [...] >> confi

Re: Q: library dependencies

On 2020-09-24, Oleg Smolsky wrote: > Hello, I'm working on an autotools-based build system and finally decided to > look into these messages: > > CXXLDlibtop.la > copying selected object files to avoid basename conflicts... > > It looks like libtool links (copies?) .o files when it finds a

Re: [EXTERNAL] Re: Q: library dependencies

On 2020-09-25, John Calcote wrote: > On Fri, Sep 25, 2020 at 10:45 AM Bob Friesenhahn > wrote: >> Exactly! It might as well be a tar file except that the 'ar' archiver >> knows how to add/update/remove files from it and that is not possible >> with a tar file. The ability to do incremental

Re: [EXTERNAL] Re: Q: library dependencies

On 2020-09-25, Howard Chu wrote: > Bob Friesenhahn wrote: > > ... static libraries do not technically have "dependencies" since they > > only represent a compilation step (no linking). If a static > > library may also be built as a shared library then it may have > > dependencies and should be

Re: [EXTERNAL] Re: Q: library dependencies

On 2020-09-25, Oleg Smolsky wrote: > On Fri, Sep 25, 2020 at 6:58 AM Bob Friesenhahn > wrote: > > Libtool convenience libraries are not "real" static libraries. > > Instead they are object files stored in an archive file. Prior to > > use (when linking using libtool) the objects are extracted

Re: Question about static and shared libraries and their usage in a binary on Windows in a autotools project

On 2021-08-10, Vincent Torri wrote: [...] > As I have said, the problem is not the lib itself. There is no problem > with the lib. The problem is with the binary : when I compile it, > there is no way to know if the library, that the binary uses, is a > static library or shared library (know ==

Re: stable release from 2.4.7 branch?

On 2023-10-22 10:48, Shterenlikht, Anton wrote: > I'm working on > > https://savannah.gnu.org/support/index.php?110947 > > and tried the development version from git. > > That version identifies itself as > > $ libtool --version > libtool (GNU libtool) 2.4.7.4-1ec8f > > yet the latest stable

Re: Problem with build

Hi, On 2022-08-01, aotto wrote: > but in ONE library I dont want to have a static library build because it > is only used as dlopen (by tcl)… [...] > pkglib_LTLIBRARIES = libtclmkkernel.la [...] > question what I have to-do to avoid a "static" library "libtclmkkernel.a" Since this seems to be a

Re: lt_dlforeach replacement?

On 2022-08-03, Zopolis0 wrote: > it looks like the intended replacement [for lt_dlforeach] is > lt_dlhandle_map. That requires a lt_dlinterface_id variable, though. Just reading the docs, I think the way it is supposed to work is you first register an interface with a null matching callback, for

Re: [sr #110796] libtool-2.4.7/build-aux/git-version-gen uses kind of a hack

On 2022-12-07, anonymous wrote: [...] > On an elderly Mac with PPC Mac OS X 10.4.11, Tiger, this was reported: > > expr: brackets ([ ]) not balanced > > It comes from this line > >76 year=`expr "$scriptversion" : '\([^-]*\)'` > > On two more up-to-date intel Macs expr worked correctly. I

Re: libtool (use with autotest)

On 2023-07-24, Simon Sobisch wrote: > > I hope to possibly get an answer by moving this question to the > appropriate lists :-) > For more context I provide the original responses to this topic. > > Am 06.07.2023 um 14:55 schrieb Jose E. Marchesi: >> >>> On 2023-07-03 17:16:59 +0200, Bruno Haible

Re: bug#67539: GNU Automake 1.16.5 FAILS one test objc-megademo

On 2023-11-30 21:46, Karl Berry wrote: Hi Dennis, libtool: compile: unable to infer tagged configuration Thanks for the report. As you surmise, apparently this needs to be reported to libtool. (Although afaik libtool is currently unmaintained, so I don't know when or if anything will get