On 2024-11-27 01:01, Ben Huntsman wrote:
> In particular, I noticed that if you add libtool to a project by
> calling LT_INIT, and then run ./configure with the
> --with-aix-soname=svr4, the .la files that get produced with the
> library_names='whatever.so.3 whatever.so', but if you call
> LT_INIT(
On 2024-08-23 13:35, Witold Interewicz wrote:
> I have 2 Qs here:
> - What is (in short/sketch) the set of conditions that causes libtool
> to add this switch '-threads' (or where may I read about it)?
It could be coming from another library you are using. For example,
some libtool library (.la f
On 2024-05-14 17:02, Bob Friesenhahn wrote:
> Since it is not allowed to wrap a target replacement in an Automake
> condition, I am finding it necessary to write new rules which use
> variables that I define.
I think it works despite the strange warning about multiple targets?
But regardless, you
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
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 versi
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
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 can
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
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
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 == ha
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 de
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 upd
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 a
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 d
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
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
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
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
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 -funwind-t
On 12/1/17, Paul "LeoNerd" Evans wrote:
> On Thu, 30 Nov 2017 15:38:20 +0100
> Thomas Jahns wrote:
>
>> The -rpath argument is for libtool (to tell it where the library will
>> be installed). To tell libtool (or ld) where to search for libraries
>> at run-time (if no .la files are installed) one
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 want to build a new system p
On 2/12/16, Evgeny Grin wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 12.02.2016 0:14, Nick Bowler wrote:
>> On 2/11/16, Evgeny Grin wrote:
>>> * change default shared lib mode from "on" to "auto" or "try" and fail
&g
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". Alternatively - i
On 2/10/16, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 10:29:40 -0500 Nick Bowler wrote:
> NB> On 2/10/16, Bob Friesenhahn wrote:
> NB> > On Wed, 10 Feb 2016, Peter Rosin wrote:
> NB> >> I agree wholeheartedly with the notion that --disable-static
> NB> &
On 2/10/16, Vadim Zeitlin wrote:
> On Wed, 10 Feb 2016 10:23:00 -0500 Nick Bowler wrote:
> NB> On 2/9/16, Vadim Zeitlin wrote:
> NB> > On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler
> NB> > wrote:
> NB> > NB> Here's the thing. Libtool is, by de
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? I just learned about i
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 builds on Windows fail due to using
On 2/9/16, Vadim Zeitlin wrote:
> On Tue, 9 Feb 2016 18:44:24 -0500 Nick Bowler wrote:
> NB> Here's the thing. Libtool is, by default, designed to transparently
> NB> support the case where building a shared library is not possible.
>
> This is, IMO, an obsolete princ
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 just fine. Libtool is anoth
cally from the nonstandard
location.
Otherwise, you might consider linking your programs with the
-R/path/to/your/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
roblems with the mailing list itself should be sent to the list
administrator:
libtool-ow...@gnu.org
Regards,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
https://lists.gnu.org/mailman/listinfo/libtool
tomake then? Presumably it should either be
generating good tarballs or failing hard. Maybe we could at
least augment distcheck to test for these artifacts and reject
the package in that case.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
https://lists.gnu.org/mailman/listinfo/libtool
This makes it so that
> the python interpreter cannot use the library: it must be shared.
It is not generally possible to link static archives into shared
libraries. The object files are usually incompatible.
Nevertheless, you should be able to force the issue by directly listing
archive
.gnu.org/cgit/libtool.git/commit/?id=da30ce4dc9554c80f1931600af2b8bbab486476e
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
https://lists.gnu.org/mailman/listinfo/libtool
portable too (at least in the future).
Well no, it doesn't follow that := assignments will become portable in
the future just because POSIX standardized ::= syntax.
Cheers,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
https://lists.gnu.org/mailman/listinfo/libtool
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 yo
On 2012-08-22 18:32 +0200, Brice Goglin wrote:
> Le 22/08/2012 16:32, Nick Bowler a écrit :
> > On 2012-08-22 15:12 +0200, Brice Goglin wrote:
> >> I am working at embedding libltdl inside our project (hwloc, an Open MPI
> >> subprojet). Our plugins are not expecte
may still be some extra checks but they should be fairly low-cost 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/
to not link against the libtool library at all.
>
> [1] http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/README?root=libffcall
>
> [2]
> http://cvs.savannah.gnu.org/viewvc/*checkout*/ffcall/configure.in?root=libffcall
>
> [3]
> http://clisp.hg.sou
ng ldd on that shell script, so 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,
--
n-time path. If
output-file is a library, add -Rlibdir to its dependency_libs, 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 t
Hi Ralf,
On 2011-04-02 10:42 +0200, Ralf Wildenhues wrote:
> * Nick Bowler wrote on Fri, Apr 01, 2011 at 04:04:21PM CEST:
> > I'm working on a project which uses libltdl to load modules, and I've
> > set it up in a manner pretty similar to what's described in the li
ld automake support the example in the
libtool manual, or does the libtool manual need to be fixed? If the
latter, is the above workaround a good one?
Thanks,
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
http://lists.gnu.org/mailman/listinfo/libtool
d into their
binaries.
--
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
___
http://lists.gnu.org/mailman/listinfo/libtool
ch can be used to filter mails 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 Technol
ar faulty library, I
tried to find out why the library got linked against 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
x27; destroys them.
Unfortunately, the only solution that I'm aware of is to avoid 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
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 tr
48 matches
Mail list logo
