-dirs=$(abs_top_builddir)/binoculars-ng/binoculars/.libs \
$@
$(LN_S) -f $$($(CABAL) \
--config-file=empty-config-file \
list-bin $@) $@
Now I would like to obtain a libtool wrapper in order to execute this hkl-test
binary with the
: Automake 1.16.90 regression mistakenly "not using Libtool"
To:
I'm seeing a problem building ntpd from a Bitkeeper repo that doesn't occur
with a make dist tarball when using Automake 2.71 and Automake 1.16.90 or
1.16.92 that reliably does not occur with Automake 1.16.5. To enabl
Automake does have a critical bug in that for a target which only
optionally has C++ sources, that target is always linked using C++.
So it should only use C++ if the "option" is selected?
Can you provide a test tree?
Without this issue, the trick of including an empty optional C++
On 5/13/24 16:37, Karl Berry wrote:
convince Automake to force libtool to link using the C++ compiler
When there are no C++ sources? Why? Just trying to understand ...
There are no C++ sources from my project, but there is a C++ compiler
used for the overall build. As clarification, this
convince Automake to force libtool to link using the C++ compiler
When there are no C++ sources? Why? Just trying to understand ...
I'm sorry Bob, but I just don't know. Maybe the just-released
libtool-2.5.0 alpha offers some new help?
If there is some bug in or feature for Aut
I have expended quite a few days already (over a 6 month span) with
attempting to convince Automake to force libtool to link using the C++
compiler. I tried optionally adding an empty C++ source file to the
target build but this does not work because then Automake always assumes
C++ linkage
On Apr 15, 2021, at 11:23 AM, Paul Smith wrote:
>
> On Thu, 2021-04-15 at 08:33 -0500, Laurence Marks wrote:
>> there should be a way to autoupdate autoXYZ files for each system
autoreconf? https://linux.die.net/man/1/autoreconf
>> without user intervention.
Post-checkout hooks? https://gi
cent fftw would be a pain.)
On Thu, Apr 15, 2021 at 9:27 AM Peter Johansson wrote:
Hi Laurence,
On 15/4/21 6:35 am, Bob Friesenhahn wrote:
Most problems seem to stem from packages providing the generated files
from Autoconf, Automake, and libtool so that end users don't need to
have the t
ig as well).
Of course, this means that everyone who wants to build the software
needs to have their own local copy of ALL the tools needed to do so,
including autoconf, automake, and libtool (actually we don't use
libtool for GNU make but...). There's never a free lunch so you just
have to decide which cost is more dear.
e to use more recent fftw would be a pain.)
On Thu, Apr 15, 2021 at 9:27 AM Peter Johansson wrote:
> Hi Laurence,
>
> On 15/4/21 6:35 am, Bob Friesenhahn wrote:
> > Most problems seem to stem from packages providing the generated files
> > from Autoconf, Automake, and libtoo
Hi Laurence,
On 15/4/21 6:35 am, Bob Friesenhahn wrote:
Most problems seem to stem from packages providing the generated files
from Autoconf, Automake, and libtool so that end users don't need to
have the tools available.
It will be easier for people here to help if you provide a bit
On Thu, 15 Apr 2021, Laurence Marks wrote:
In the same way as autoXZY sets up Makefiles in an OS independent fashion,
there should be a way to autoupdate autoXYZ files for each system without
user intervention. (I don't mean automake itself or similar, I do mean only
the local files.) In an idea
g between machines/OS to test (as gcc & now gfortran are moving
targets) I almost always have to reconfig. Libtool is part of the issue,
but there are also couplings to aclocal macros and sometimes other
components as well.
In the same way as autoXZY sets up Makefiles in an OS independent fashion,
ther
On Wed, 14 Apr 2021, Laurence Marks wrote:
It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2
versus 2.4.6 (for instance, those are just invented numbers). In many cases
aclocal, libtool, ltmain.sh and maybe a few others do not work if they were
created with a different
It is not timestamp issues, it is version issues -- e.g. libtool 2.4.2
versus 2.4.6 (for instance, those are just invented numbers). In many cases
aclocal, libtool, ltmain.sh and maybe a few others do not work if they were
created with a different autoXYZ version than is on the computer where they
On Wed, 14 Apr 2021, Laurence Marks wrote:
I have some software which has been "fine" for about 15 years, with one
exception: every 6-12 months or so when I (or students/others) compile it
we run into version problems. The typical ones are version mismatch between
libtool and/or acloc
Hi Laurence - sorry, but I can't imagine how to automatically correct
version mismatches. The possible problems are both unpredictable and
endless, seems to me. Maybe others here have some more useful
idea. --best, karl.
I have some software which has been "fine" for about 15 years, with one
exception: every 6-12 months or so when I (or students/others) compile it
we run into version problems. The typical ones are version mismatch between
libtool and/or aclocal (called from libtool). While I can futze a
Hi all,
I am using software that specifies a nodist_EXTRA_*_SOURCES dummy source
file in its top-level Makefile.am, as recommended by the Automake manual
to get the C++ linker to combine several libtool convenience libraries
for subdirectories:
https://www.gnu.org/software/automake/manual
> The overhead attributed to libtool seems rather high. Is there
> something about your execution environment or your libtool usage which
> causes more overhead than usual?
Not that I am aware of, its the standard GNU libtool in
Slackware64-current.
> How does slibtool validate arg
On Mon, 25 Jun 2018, or...@fredslev.dk wrote:
I’m curious - it’s neat that slibtool exists, but if you need
functionality offered by libtool then why not just use libtool?
Frankly libtool is 12,000+ line shell script which is hard to
understand, maintain, fix and is rather slow.
Agreed.
A
> I’m curious - it’s neat that slibtool exists, but if you need
> functionality offered by libtool then why not just use libtool?
Frankly libtool is 12,000+ line shell script which is hard to
understand, maintain, fix and is rather slow.
A while ago with my 6 core AMD FX-6350 cpu I
On Sat, Jun 23, 2018 at 1:00 AM or...@fredslev.dk wrote:
> Hi,
>
> I am using the GNU libtool alternative slibtool which has some benefits
> such as a smaller code base, actively maintained and a huge performance
> boost.
I’m curious - it’s neat that slibtool exists,
Hi,
I am using the GNU libtool alternative slibtool which has some benefits
such as a smaller code base, actively maintained and a huge performance
boost.
The problem is that because slibtool doesn't work in the top directory
of a project it doesn't know if it should build with --ena
t; >
> > .PHONY: $(objdir)/bar.lo:
> >
> > $(objdir)/bar.lo:
> >
> > to your Makefile.am
> >
> > On 15.02.2018 3:59, sea star wrote:
> >> Hi,
> >>
> >> I have a set of object files built by libool and other set of objec
2018 3:59, sea star wrote:
>> Hi,
>>
>> I have a set of object files built by libool and other set of object files
>> that are not built by libool. The non-libtool object files are created
>> outside of my project to which I have limited access.
>>
>> I have
Please try to add
.PHONY: $(objdir)/bar.lo:
$(objdir)/bar.lo:
to your Makefile.am
On 15.02.2018 3:59, sea star wrote:
> Hi,
>
> I have a set of object files built by libool and other set of object files
> that are not built by libool. The non-libtool object files are creat
Hi,
I have a set of object files built by libool and other set of object files
that are not built by libool. The non-libtool object files are created
outside of my project to which I have limited access.
I have the following in my Makefile.am:
objdir=/nfsmnt/projx/build/release/
OBJS="$(o
Hi,
I have a set of object files built by libool and other set of object files
that are not built by libool. The non-libtool object files are created
outside of my project to which I have limited access.
I have the following in my Makefile.am:
objdir=/nfsmnt/projx/build/release/
OBJS="$(o
I recently posted a question about this to stackoverflow:
https://stackoverflow.com/questions/44979427/overriding-installation-path-in-shared-libraries-built-with-automake-libtool-dur
Rather than repeat the posting here, I'll just post the synopsis of the problem:
Starting with OS X
Hello,
I've run into the problem where a compiler we regularly use (NAG Fortran
compiler) has flag conventions that are at odds with libtool (i.e. nagfor uses
-Wc,opt to pass opt to the C compiler it uses as backend). For this reason I'd
like to add the compiler options to FCFLAGS
\
*/libtool.m4 \
On 21.07.2016 14:26, Manjesh HS wrote:
> Hi,
> I have a software project that uses GNU autotools for its build mechanism.
>
> I was earlier building this project successfully on an *RHEL5.6* host
> having *automake - 1.9.6, autoconf - 2.59, m4 - 1.4.5 and libtool - 1.5
Hi,
I have a software project that uses GNU autotools for its build mechanism.
I was earlier building this project successfully on an *RHEL5.6* host
having *automake - 1.9.6, autoconf - 2.59, m4 - 1.4.5 and libtool - 1.5.22*
packages. Now I migrated to an *RHEL7.2* host having *automake - 1.15
I have just found out (by reading libtool source) that Android does not
support versioning so actually libtool behaviour is correct, it was issue
in Cerbero build system that it has expeced *.so.*.
Thanks!
Marcin
Hello,
I am seeking for help with awkward issue with libtool while building this
library: http://github.com/mspanc/vspec
When i build it on my ubuntu 14.04 box, it works fine, add during make
install it creates appropriate .so.VERSION_INFO symlinks.
However, when I try to cross compile it using
Hi Kees-Jan,
On 12/30/2015 05:52 AM, Kees-Jan Dijkzeul wrote:
On Tue, Dec 29, 2015 at 8:46 PM, Bob Friesenhahn
wrote:
>Try adding 'make clean' to your build steps.
>
>The best thing to do is to build outside of the source tree and use a
>separate build directory for each configure incantation
On Wed, 30 Dec 2015, Kees-Jan Dijkzeul wrote:
On Tue, Dec 29, 2015 at 9:14 PM, Gavin Smith wrote:
You want not to rebuild files that don't need to be rebuilt.
Although I tend to agree, we may differ on opinion on the importance
of this. I'd argue that it is much more important to not forget
On Tue, Dec 29, 2015 at 9:14 PM, Gavin Smith wrote:
>
> You want not to rebuild files that don't need to be rebuilt.
Although I tend to agree, we may differ on opinion on the importance
of this. I'd argue that it is much more important to not forget
rebuilding files that actually needed to be reb
On 29 December 2015 at 19:52, Kees-Jan Dijkzeul wrote:
> Either would obviously work, but kind of defeat the purpose of having
> incremental builds, and unnecessarily load the buildserver. A
> solution where I could do an incremental build after a configure
> incantation would be much preferred.
Hi Bob,
Thanks for your reply
On Tue, Dec 29, 2015 at 8:46 PM, Bob Friesenhahn
wrote:
> Try adding 'make clean' to your build steps.
>
> The best thing to do is to build outside of the source tree and use a
> separate build directory for each configure incantation.
Either would obviously work,
make install
The second make install fails for some libraries, with the message
libtool: install: error: cannot install `' to a directory
not ending in ${HOME}/opt/1
Apparently, libname.la needs to be rebuilt after the prefix changed,
but automake didn't generate the rules to do so.
Hi,
On my buildserver, I'd like to do something along the lines of
# build 1
./configure --prefix=${HOME}/opt/1 && make && make install
# build 2 (incrementally)
./configure --prefix=${HOME}/opt/2 && make && make install
The second make install fails for som
". The
> Makefile.am part that builds this library reads:
>
> perlextdir = $(PERL_EXT_LIB)
> perlext_SCRIPTS = perl5/mummer.pm
> perlext_LTLIBRARIES = perl5/mummer.la
> perl5_mummer_la_SOURCES = perl5/swig_wrap.cpp $(SWIG_SRC)
>
> plus some other flags set in _CPPFLAGS, _LDFLAGS
/mummer.pm
perlext_LTLIBRARIES = perl5/mummer.la
perl5_mummer_la_SOURCES = perl5/swig_wrap.cpp $(SWIG_SRC)
plus some other flags set in _CPPFLAGS, _LDFLAGS etc. Could really LIBTOOL
build a shared object in the .libs directory that could not be loaded by
"bootstrap mummer;"?
In other words, for t
On 24 July 2015 at 20:13, Guillaume Marcais wrote:
> I am improving/writing a C++ project (called MUMmer) which creates a shared
> library with libtool. In the same project, I also create a SWIG binding to
> access in Perl some of the functionality of this shared library.
>
> Libt
Hello all,
I am improving/writing a C++ project (called MUMmer) which creates a shared
library with libtool. In the same project, I also create a SWIG binding to
access in Perl some of the functionality of this shared library.
Libtool creates the shared library in a hidden directory:
.libs
[Adding Automake]
On 2015-03-23 16:00 +, Gary V. Vaughan wrote:
> > On Mar 23, 2015, at 2:42 PM, Bob Friesenhahn
> > wrote:
> > > On Mon, 23 Mar 2015, Christian Rössel wrote:
[...]
> > > I discovered some files in
> > > http://ftpmirror.gnu.or
> -Original Message-
> From: Thomas Jahns [mailto:ja...@dkrz.de]
> Sent: Friday, March 06, 2015 1:46 AM
> To: Andy Falanga (afalanga)
> Cc: automake@gnu.org
> Subject: Re: How to use ld options correctly for --whole-archive in
> automake and libtool
>
> >&g
On 03/05/15 18:28, Andy Falanga (afalanga) wrote:
-Original Message-
From: Thomas Jahns [mailto:ja...@dkrz.de]
Sent: Wednesday, March 04, 2015 5:45 PM
To: Andy Falanga (afalanga)
Cc: automake@gnu.org
Subject: Re: How to use ld options correctly for --whole-archive in
automake and libtool
Hello Vincent,
On 03/05/15 18:43, Vincent Torri wrote:
I would also use $(top_builddir) instead of relative path. It could
help when building in another directory than the source one (like with
make distcheck)
I cannot see how .. would ever refer to the source tree and since libhwmgmt.la
is g
> -Original Message-
> From: Vincent Torri [mailto:vincent.to...@gmail.com]
> Sent: Thursday, March 05, 2015 1:26 PM
> To: Andy Falanga (afalanga)
> Cc: Thomas Jahns; automake@gnu.org
> Subject: Re: How to use ld options correctly for --whole-archive in
> automake an
>> Subject: Re: How to use ld options correctly for --whole-archive in
>> automake and libtool
>>
>> >
>> >> But what exactly is the problem with using e.g. ../Shared/HwMgmt/
>> >> libhwmgmt.la? That sata.so will then require libhwmgmt.so? libtool
>&
> -Original Message-
> From: Vincent Torri [mailto:vincent.to...@gmail.com]
> Sent: Thursday, March 05, 2015 10:44 AM
> To: Andy Falanga (afalanga)
> Cc: Thomas Jahns; automake@gnu.org
> Subject: Re: How to use ld options correctly for --whole-archive in
>
e" are not listed
> between this option. Instead, they are listed earlier and *nothing is
> listed* between -Wl,--whole-archive -Wl,--no-whole-archive. I assume that
> libtool is doing this for me.
>
I don't know if will work in your case, but I managed to work around
a
use ld options correctly for --whole-archive in
>> automake and libtool
>>
>>
>> This is, from my point of view not so much an automake issue but a
>> libtool problem: libtool for some reason I don't know decided to make -
>> Wl, be the prefix for options t
> -Original Message-
> From: Thomas Jahns [mailto:ja...@dkrz.de]
> Sent: Wednesday, March 04, 2015 5:45 PM
> To: Andy Falanga (afalanga)
> Cc: automake@gnu.org
> Subject: Re: How to use ld options correctly for --whole-archive in
> automake and libtool
>
>
xpect them,
but when make runs, the libraries I've specified to be included as
"whole-archive" are not listed between this option. Instead, they
are listed earlier and *nothing is listed* between -Wl,--whole-
archive -Wl,--no-whole-archive. I assume that libtool is doing this
I find that Makefile.in
and the final Makefile have things where I expect them, but when make runs, the
libraries I've specified to be included as "whole-archive" are not listed
between this option. Instead, they are listed earlier and *nothing is listed*
between -Wl,--whole-archive
Thanks!!!
_
From: Diego Elio Pettenò [mailto:flamee...@flameeyes.eu]
Sent: Sunday, September 07, 2014 11:10 AM
To: Arthur Schwarz
Cc: automake@gnu.org
Subject: Re: [NEWBIE] How do you make a library w/libtool
I think you're definitely misunderstanding how the tools fit tog
rsion of my software and am trying to
> make a library, right now as a UNIX library and soon using libtool for a
> dynamic library. The static library does not work and I don't see an error
> message. It seems to configure correctly (using autoreconf) but no *.gz
> file
> is g
UNIX library and soon using libtool for a
dynamic library. The static library does not work and I don't see an error
message. It seems to configure correctly (using autoreconf) but no *.gz file
is generated. I can't figure what's wrong and can't go to generating a
dynamic library
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
On 6 September 2014 13:50, Arthur Schwarz wrote:
> I've successfully made a executable version of my software and am trying to
> make a library, right now as a UNIX library and soon using libtool for
I've successfully made a executable version of my software and am trying to
make a library, right now as a UNIX library and soon using libtool for a
dynamic library. The static library does not work and I don't see an error
message. It seems to configure correctly (using autoreconf) b
environment
into executables. this solves my libtool issues and leaves no traces
after "make install".
project/main/Makefile.am
noinst_SCRIPTS = program
bin_PROGRAMS = program.real
program_real_LDADD = ../lib/library.la
program_real_LDFLAGS = -rpath ${pkglibdir} -Wl,--enable-new-dt
Hi Thomas.
thanks for your reply.
On Thu, Jan 16, 2014 at 03:56:04PM +0100, Thomas Jahns wrote:
> ./libtool --mode=execute main/program
digging deeper, it looks like libtool cannot resolve this. it would have
to guess the location from where files in ${pkglibdir} have come. or
take some ex
Hello Felix,
not an automake issue, but...
On 01/16/14 13:02, Felix Salfelder wrote:
[rpath in uninstalled binary]
The normal mode of using libtool to run the binary with adjusted paths in
circumstances like yours is
./libtool --mode=execute main/program
Regards, Thomas
--
Thomas Jahns
DKRZ
Hi there.
i have a problem with LTLIBRARY modules and the executables wrapper.
consider the following setup.
project/lib/Makefile.am
lib_LTLIBRARIES = library.la
project/plugins/Makefile.am
programdir = $(pkglibdir)
program_LTLIBRARIES = plugin.la
plugin_la_LDFLAGS = -module
project/main/Makef
---
>
> Where do we have to make which checks?
>
> Do we need a check for librt in the libfoo package?
>
> Do we have to mention the librt link option somewhere in the progbar package?
>
> Thx for any help,
> Steffen
>
> PS: FUP set to
>
>
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
Okay, Robert already answered but...
On 16/07/2013 15:56, Steffen Sledz wrote:
> FOO_LDFLAGS="-L$with_libfoo_path/lib -lfoo"
[...]
> progbar_LDFLAGS = $(FOO_LDFLAGS)
This is simply wrong, whether or not it works after adding LT_INIT.
-lfoo is a library not an LDFLAG.
It should be passed t
On 16.07.2013 17:47, Robert Boehne wrote:
> That said - It looks to me like you're not *using* libtool to do your linking.
> Libtool's la files contain all the dependencies that a library needs.
> This is a big help when using static archives because they need
> to have ev
Steffen,
I would suggest asking questions about Libtool on a libtool mailing list.
That said - It looks to me like you're not *using* libtool to do your
linking.
Libtool's la files contain all the dependencies that a library needs.
This is a big help when using static archives be
Sorry, if this is a faq, but i didn't found a clear answer searching around.
Given situation: We have a library called e.g. libfoo which uses e.g. mq_open
from librt. Than we have a program e.g. called progbar which requires libfoo
(and therefor also librt).
Our current solution looks like this
d by autoreconf; but then I see, in the output you've reported:
>>
>>>autoreconf: configure.ac: not using Libtool
>>
>> which means that might still be something wrong with your configure.ac,
>> or some bug in autoreconf. If you want more help, you should
On Nov 8, 2012, at 1:19 PM CST, Stefano Lattarini wrote:
> On 11/08/2012 07:56 PM, Bruce Korb wrote:
>>
>>> autoreconf: configure.ac: not using Libtool
[…]
>>> lib/Makefile.am:31: error: Libtool library used but 'LIBTOOL' is undefined
>>> lib/Make
-install --verbose --symlink
>> autoreconf: Entering directory `.'
>> autoreconf: configure.ac: not using Gettext
>> autoreconf: running: aclocal --force -I m4
>> autoreconf: configure.ac: tracing
>> autoreconf: configure.ac: not using Libtool
>> autoreconf: runn
ectory `.'
> autoreconf: configure.ac: not using Gettext
> autoreconf: running: aclocal --force -I m4
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: /usr/bin/autoconf --force
> autoreconf: running: /usr/bin/autoheader --force
&g
On 02/11/2012 16:16, Václav Zeman wrote:
> How can I make this work as you have suggested without $(top_builddir)?
Okay here's my rule of thumb (Stefano can give you the informed,
developer opinion):
- if it's declared in the same makefile, don't use $(top_builddir);
- if it's declared on a dif
_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>
> assignment -- make doesn't know how to proceed, and bails out.
>
> So better to just remove the useless extra '$(top_builddir)/src'
> indirection. Not only this fixes the error, but is also clearer
> t
On 11/02/2012 09:18 AM, Václav Zeman wrote:
> On 1 November 2012 17:42, Diego Elio Pettenò wrote:
>> On 01/11/2012 09:18, Vincent Torri wrote:
>>> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>>
>> Don't use $(top_builddir) and it should work just fine.
> Is there a rationale be
On 1 November 2012 17:42, Diego Elio Pettenò wrote:
> On 01/11/2012 09:18, Vincent Torri wrote:
>> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
>
> Don't use $(top_builddir) and it should work just fine.
Is there a rationale behind this? I am not saying it is wrong, I just
want
On 01/11/2012 09:18, Vincent Torri wrote:
> lib_eo_libeo_la_LIBADD = $(top_builddir)/src/lib/eina/libeina.la
Don't use $(top_builddir) and it should work just fine.
--
Diego Elio Pettenò — Flameeyes
flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Hey
I want to build to libraries names eina and eo within a single
Makefile.am. They are in the following tree structure:
src/Makefile.am
src/lib/eina/
src/lib/eo
eo depends on eina. The Makefile.am file is (i've stripped the unneeded parts)
AUTOMAKE_OPTIONS = subdir-objects
lib_LTLIBRARIES =
On Monday 26 September 2011, GAVA Cédric wrote:
> Dear all
>
> My objective is (simply) to pass -Wall when I compile my library...
>
Ah, ok, so you want to pass `-Wall' to gcc. Good.
> And I would like to know the "best way" to do it regarding the
> philosophy of Autotools...
>
This is a legitim
le warnings.
So Ok, I was wrong
So I guess I shall modify CFLAGS...
How to do it to preserve the flags automatically added by default by Automake
and Libtool (I don't want to get completely out of the automated process by
setting me entire custom CFLAGS) ?
Best regards
PS : [@Stefano] Thank you for your answer...
t hasn't, nor it should have,
any effect on the other autotools (libtool, aclocal, autoconf, autoheader),
as we well as on the compiler or other tools used in the Makefiles.
> And, in the end, it's not visible in the libtool command launched...
>
And that's good.
> What do
Hi all,
I have too projects which using Automake and Libtool. The first
project distributes a static library, which will be linked into the
second project in the whole-archive mode. Is that possible?
I noticed that Libtool whole-archive a library into another only if
the former is configured as
On Thu, 30 Jun 2011 14:38:49 +0200, Pippijn van Steenhoven wrote:
On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote:
From: Pippijn van Steenhoven
Date: Mon, Jun 20, 2011 at 4:55 PM
Subject: Re: libtool relink problem
To: automake@gnu.org
On Sun, Jun 19, 2011 at 03:40:06PM
On Wed, Jun 29, 2011 at 05:14:19PM +0200, Emmanuel Engelhart wrote:
>
>> From: Pippijn van Steenhoven
>> Date: Mon, Jun 20, 2011 at 4:55 PM
>> Subject: Re: libtool relink problem
>> To: automake@gnu.org
>>
>>
>> On Sun, Jun 19, 2011 at 03:40:06PM +0530
From: Pippijn van Steenhoven
Date: Mon, Jun 20, 2011 at 4:55 PM
Subject: Re: libtool relink problem
To: automake@gnu.org
On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal wrote:
Hi,
I am facing a problem with libtool. While installing it complains a
relink required and while
On Sun, Jun 19, 2011 at 03:40:06PM +0530, Santhosh Thottingal wrote:
> Hi,
> I am facing a problem with libtool. While installing it complains a
> relink required and while doing so it tries to link against the
> shared library instead of static library.
> Well, the problem is b
Hi,
I am facing a problem with libtool. While installing it complains a
relink required and while doing so it tries to link against the
shared library instead of static library.
Well, the problem is better explained in this thread
http://sourceware.org/ml/automake/2004-07/msg00127.html with
Hi Ralf,
On 4/19/11 10:10 AM, "Ralf Wildenhues" wrote:
>Hello Justin,
>
>* Too, Justin A. wrote on Tue, Apr 19, 2011 at 06:52:33PM CEST:
>> The libraries in LIBADD are the convenience libraries generated in
>> subdirectories. I would like to perform the link step of all of the
>> intermediate l
Hello Justin,
* Too, Justin A. wrote on Tue, Apr 19, 2011 at 06:52:33PM CEST:
> The libraries in LIBADD are the convenience libraries generated in
> subdirectories. I would like to perform the link step of all of the
> intermediate libraries into libprogram.la on a ramdisk.
Why not put the whole
Hi all,
At the top-level, I'm building my program's libtool library:
lib_LTLIBRARIES = libprogram.la
libprogram_la_sources = . . .
libprogram_la_LIBADD = . . .
The libraries in LIBADD are the convenience libraries generated in
subdirectories. I would like to perform the link step
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
Hello Nick,
* 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 libtool
> manual (10.3 Linking with dlopened modules, http://x
Hello,
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 libtool
manual (10.3 Linking with dlopened modules, http://xrl.us/bjk9e5).
In that section, the manual recommends to use a weak library inte
Hello Hugh,
let's keep the list in Cc:, I dislike private communication about things
interesting for the public at large. Thanks.
* Hugh Dickinson wrote on Tue, Sep 28, 2010 at 09:34:13AM CEST:
> By the way, is the feature that you use for doing the suffix
> substitution (":.c=.cc") documented a
Hello Martin,
* Martin Kalbfuss wrote on Thu, Sep 23, 2010 at 08:08:36PM CEST:
> If I do mylib_la_LIBADD = libSDL.la
>
> It says,
>
> make[1]: Entering directory
> `/home/martin/Desktop/sk/schwarzerkaffee/src'
> make[1]: *** No rule to make target `libSDL.la', needed by `libsk.la'.
The idea is
Hi, I try to use libtool for my project, It runs fine as long as libSDL
is added as dependency to the program directly. But I thought, I could
add a library as dependency of a library. But it isn't working.
my wrapping library is libsk.la which depends on libSDL.la which is in
my path.
If
1 - 100 of 501 matches
Mail list logo
