On Mon, 27 Jun 2016, Bob Friesenhahn wrote:
The good news is that libtool will already automatically link dependency
libraries when you build something which depends on 'A' and the .la file for
'A' is present. In other words, libtool should handle the problem
automatically as long as you
On Mon, 27 Jun 2016, Alex wrote:
$ ./configure --disable-shared --enable-static --prefix=/usr
$ make && make install
But when I build *A* afterwards the following warning appears:
*** Warning: This system can not link to static lib archive /usr/lib/
libogg.la.
*** I have the capability to
Hello, I wonder if this would be a bug or something directly unsupported.
I'm building a shared library *A* on Windows using MSYS (bash, gcc, etc.).
*A* depends on *B*, so it needs to be built first and as long as both are
built to be shared libraries everything goes well.
However I'd like to
$ make CFLAGS='-arch x86_64' CXXFLAGS='-arch x86_64' LDFLAGS='-framework
CoreFoundation -framework CoreServices
-L$HOME/build/sfAgent/libs/Release_Static/lib'
But when the build goes to link an executable:
/bin/sh ./libtool --tag=CXX --mode=link c++ -arch x86_64 -framework
I'm experiencing a problem linking with static libraries on Darwin (Mountain
Lion). I'm getting this warning:
ld: warning: ignoring file ./.libs/libxqilla.a, file was built for archive
which is not the architecture being linked (x86_64): ./.libs/libxqilla.a
…even though I'm pretty confident
twice):
From: Vadim Zeitlin vz-libt...@zeitlins.org
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was
disabled.
If -no-undefined was not specified
twice):
From: Vadim Zeitlin vz-libt...@zeitlins.org
Date: Thu, 7 Jul 2011 17:26:43 +0200
Subject: [PATCH] Don't fall back to static libraries if building them was
disabled.
If -no-undefined was not specified
the offending code and everything compiled successfully, with the
above warning still appearing.
When the time came to compile actual executables, libtool correctly linked in
both the shared and static libraries as requested, so everything now works as
expected!
Cheers,
Adam
*** Warning: Trying to link with static lib archive
/usr/i486-mingw32/lib/libboost_filesystem-mt-s.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not
On Wednesday, April 27, 2011 22:49:11 Adam Nielsen wrote:
I'm trying to cross-compile a library under Linux to produce a Win32 .dll.
It needs to link in with static Boost libraries (which were also cross
compiled on the same machine) but libtool seems to refuse to do this:
*** Warning:
*** Warning: Trying to link with static lib archive
/usr/i486-mingw32/lib/libboost_filesystem-mt-s.a.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not
Hi all,
I'm trying to cross-compile a library under Linux to produce a Win32 .dll. It
needs to link in with static Boost libraries (which were also cross compiled
on the same machine) but libtool seems to refuse to do this:
*** Warning: Trying to link with static lib archive
I want to explain the question a bit more.
I have in a .dll library implemented, e.g.:
FreeContextBuffer(NULL);
For this function I need to refer to libsecur32.a.
How can I do that?
libhello_la_LDFLAGS = -no-undefined -avoid-version -lsecur32
does not work with cygwin.
Thanks for help
Hanro
I ran in to a problem using libtool to generate both shared and static
libraries with convenience archives (on cygwin, but I believe this is
cross-platform). Working with git-master xz utils, with some local
patches, I saw the following:
/bin/sh ../../libtool --tag=CC --mode=link gcc -std
On Sun, 28 Jun 2009, Charles Wilson wrote:
So, when we get around to linking the actually installable library, both
the DLL and the static' archive contain the same .o's -- the ones
compiled with the pic flags -DDLL_EXPORT and -DPIC.
This is a problem, because now the static archive contains
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each
Ralf Wildenhues wrote:
* Roumen Petrov wrote on Fri, Feb 27, 2009 at 10:07:19PM CET:
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check
LRN wrote:
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be
OK, maybe it's a stupid question, but i have to ask anyway.
MinGW ships some static .a libraries. How do i link these to shared .dll
libraries? It seems that libtool always performs a check (filemagic in
my case) on each -lname argument, and to pass that check the library has
to be x86 archive
* Ed Hartnett wrote on Tue, May 13, 2008 at 09:46:11PM CEST:
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
(The .a file is always a static library, right?)
Not on AIX. AIX differentiates between the notion of 'shared object'
and 'shared library'.
Are there other systems where this can
Howdy all!
What does it mean while I get the following response to ./libtool
--features
bash$ ./libtool --features
host: powerpc-ibm-aix5.1.0.0
enable shared libraries
disable static libraries
Does this mean that static libraries will not be built on this
platform?
Yet my build is having
(The .a file is always a static library, right?)
Not on AIX. AIX differentiates between the notion of 'shared object'
and 'shared library'.
A shared object is a single object file that has the Shared object
SHROBJ flag in the XCOFF header. A shared object normally has a name of
the form
On Tue, 13 May 2008, Ed Hartnett wrote:
Yet my build is having the problem of installing only the static
library.
(The .a file is always a static library, right?)
No. There is an OS called AIX which can deliver shared libraries with
this extension. :-)
Bob
[EMAIL PROTECTED] [EMAIL PROTECTED] writes:
(The .a file is always a static library, right?)
Not on AIX. AIX differentiates between the notion of 'shared object'
and 'shared library'.
A shared object is a single object file that has the Shared object
SHROBJ flag in the XCOFF header. A
From: Ed Hartnett [EMAIL PROTECTED]
Date: Tue, 13 May 2008 07:33:02 -0600
(The .a file is always a static library, right?)
Not on AIX.
A .a file can be a shared library, a static library, or
some combination of the two.
Dan
___
that
is tested on this string only accepts import libraries which makes it
imposible to link against static libraries.
Is this intentional?
Yes, I think this was a conscious decision made by the Cygwin/MinGW
maintainers of Libtool.
Why would you want to stop people linking against static
libraries which makes it
imposible to link against static libraries.
Is this intentional? Why would you want to stop people linking against
static libraries?
I've attached a patch which fixes it for my by just allowing it to
match against static libraries as well.
Thanks,
- Neil
--- libtool-2.1b
Hello Henning,
* Henning Nielsen Lund wrote on Sat, Feb 16, 2008 at 11:04:47AM CET:
I am working on making it more easy to make shared libraries (Patch #6416)
and using them for AmigaOS4.
Now my big problem comes... when we link our executables using shared
objects, do we need to include
Hello
I am working on making it more easy to make shared libraries (Patch #6416)
and using them for AmigaOS4.
Now my big problem comes... when we link our executables using shared
objects, do we need to include -use-dynld -Lsobjs: or -use-dynld
-L/sobjs to the line.
Is it in libtool, autoconf
-libraries
The answer from Mike is correct, they're static libraries that other
programs may link to if wanted.
How do you plan to use this library?
I am trying to build some program under Cygwin/X and it seemed that there is
some sort of problem with linking to one of the libraries (*.la
... no
but, after make install the package did installed in the installation
folder files of the type *.la *.dll.a.
My goal is to create only static libraries of this module, am I missing
something ?
If you don't need to have the libraries installed for a convenience
library, use noinst_*. See:
http
the package did installed in the installation
folder files of the type *.la *.dll.a.
My goal is to create only static libraries of this module, am I missing
something ?
thanks in advance
Azencot Omri
___
http://lists.gnu.org/mailman/listinfo/libtool
Hello Roger,
* Roger March wrote on Fri, Jan 05, 2007 at 08:52:57PM CET:
I have been using libtool 1.5.18 for my builds for awhile. The
applications link against libraries containing both static and shared
versions. When 1.5.18 is linked with the '-static' flag, it seems to
pretty much
I have been using libtool 1.5.18 for my builds for awhile. The
applications link against libraries containing both static and shared
versions. When 1.5.18 is linked with the '-static' flag, it seems to
pretty much select a static version for every library it can. When
1.5.22 is used it seems
I just noticed that the messages that i have sent are coming through
slightly corrupted. I am going to have to find out what is causing the
corruption when i get back to work, but anyway. The automake variables i
have provided are being replaced with:
address @ hidden @
That is not what they are
a look at the -version-info option, and that does not quite
achieve what I desire, however the -release tag is what I want. The
problem is however that the static libraries are still named
libatcppunit.a and not libatcppunit-1.0.6.a as I would have expected.
So various versions of the static library can
in time
| on my machine.
|
| I had a look at the -version-info option, and that does not quite
| achieve what I desire, however the -release tag is what I want. The
| problem is however that the static libraries are still named
| libatcppunit.a and not libatcppunit-1.0.6.a as I would have expected.
| So
Good day!
The problem, mentioned in
http://lists.gnu.org/archive/html/bug-libtool/2005-10/msg00040.html,
appears to persist in both 1.5.22 and HEAD.
Just FYI, hope, that You haven't forgotten it:)))
___
Bug-libtool mailing list
Excuse me, i have forgotten the attach in last message, now i resend.
Good day!
There is a following problem using CC v5.5 (v5.6 from Studio 10 does
show the same behaviour).
I compile the sources (attached).
test1 prints the message, while test2 doesn't.
That is because when we compile
Hi Yuri,
* Pooh wrote on Mon, Oct 31, 2005 at 11:31:24AM CET:
There is a following problem using CC v5.5 (v5.6 from Studio 10 does
show the same behaviour).
I compile the sources (attached).
test1 prints the message, while test2 doesn't.
That is because when we compile static library
Howard Chu wrote:
One more time, shouting into the senseless void...
If these so-called convenience libraries are meant to be linked in
whole, they should not be ar archives at all. You should just link them
directly into a relocatable object file:
ld -r -o convenience.obj *.o
I am listening,
.
Parts of static libraries cannot be linked into shared libraries, as
shared libs need to be compiled as position independent code (ld.so on
ix86 linux can work around that by mapping the offending library into a
private mapping and relocating it, but that is a huge waste of memory
and not portable
of the linker.
Parts of static libraries cannot be linked into shared libraries, as
shared libs need to be compiled as position independent code (ld.so on
ix86 linux can work around that by mapping the offending library into a
private mapping and relocating it, but that is a huge waste of memory
On Sun, 26 Sep 2004, Simon Richter wrote:
1. Libtool takes _all_ modules from libauth.la, and puts them into
libauthuserdb.la. I only want the modules that libauthuserdb.la actually
needs.
A convenience library, as a libtool library that is not installed is
called, is linked into each object
static libraries, which I'll refer to as component
libraries. Here's an example component library:
libauth_la_SOURCES=auth.h authexit.c chain.c checkpassword.c \
[ more sources go here ]
libauth_la_LDFLAGS=-static
libauth.la is not going to get installed by the final application
I have been unable to create a static library of java sources using
libtool.
$ cat Makefile.am
noinst_LTLIBRARIES = libhello.la
libhello_la_SOURCES = HelloWorld.java
$ make libhello.la
/bin/sh ./libtool --mode=link gcj-3.4 -g -O2 -o libhello.la HelloWorld.lo
rm -fr .libs/libhello.la
creating
|why libtool doesn't use versioning for static libraries.
|
|My question is - is the lack of versioning for static libraries a
|limitation of libtool or is a something that pkg-config should work
|around?
|
|
| This sounds like a libtool bug to me.
Agreed. I presume that because static libs do
), following command is run:
pkg-config --libs glib-2.0
The result is -lglib-2.0. pkg-config doesn't know that static linking
was requested. There is no option for that. So the output is the same
for shared and static libraries.
For this to work, libglib-2.0.a should be available to the linker
On Wed, 17 Dec 2003, Pavel Roskin wrote:
libhello-5.6.so is created in .libs, but libhello-5.6.a is not. Neither
is it created during installation.
The problem may be in pkg-config, but if so, I need very good arguments
why libtool doesn't use versioning for static libraries.
My question
On 26.09.2003 02:44:28 [EMAIL PROTECTED] wrote:
Bob Friesenhahn wrote:
On Thu, 25 Sep 2003, Bernhard Rumpler wrote:
When I try to link static libraries, then a warning Linking the shared
library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a
is
not portable! is displayed. What
Tor Lillqvist wrote:
I have found that to ensure a mixture of Cygwin-based tools (for
instance shell scripts that run under a Cygwin shell, or Cygwin Perl
scripts) and native (mingw) tools interoperate reliably one needs to
make sure that the same paths are valid (and point to the same files)
in
Hi,
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
The problem is that the library consists of some
sub-packages (sub-directories) that are linked
[EMAIL PROTECTED] wrote:
Hi,
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
The problem is that the library consists of some
sub-packages (sub-directories
PROTECTED] wrote:
Hi,
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
The problem is that the library consists of some
sub-packages (sub-directories
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote:
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
Alas, it is necessory for all libraries that your DLL
On Thu, 25 Sep 2003, Guido Draheim wrote:
[EMAIL PROTECTED] wrote:
*** Warning: This system can not link to static lib archive
c:/libpath/lib/libfoo.la.
^
How did you do that? -- guido
Since libtool on cygwin usually generates unix/cygwin-style paths
(starting
On Thu, 25 Sep 2003, Guido Draheim wrote:
If all
dependencies are resolved then a dll should be there
as $subdir/.libs/*.dll - check the content of the .la
files in $subdir/*.la whether it has been configured
correctly to create dynalibs (it's a text file). Then
do the next step.
hmm, what
On Thu, 25 Sep 2003, Bernhard Rumpler wrote:
On Thu, 25 Sep 2003, Guido Draheim wrote:
[EMAIL PROTECTED] wrote:
*** Warning: This system can not link to static lib archive
c:/libpath/lib/libfoo.la.
^
How did you do that? -- guido
Since libtool on cygwin
On Thu, 25 Sep 2003, Bob Friesenhahn wrote:
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote:
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created,
no .dlls. What could be the reason for this?
Alas
Bob Friesenhahn writes:
While Cygwin does provide a compiler mode in which it may compile
programs which use the MinGW library, there may be some problems with
crossing over between the two environments.
This might be obvious to many, but anyway:
I have found that to ensure a mixture of
On Thu, 25 Sep 2003, Bob Friesenhahn wrote:
The easiest way to deal with MinGW is to use the MSYS shell which
provides a limited Cygwin-like shell capable of supporting configure,
make, and libtool, while automatically transforming Unix paths into
the Windows paths that the tools require.
On Thu, 25 Sep 2003, Bernhard Rumpler wrote:
On Thu, 25 Sep 2003, Bob Friesenhahn wrote:
On Thu, 25 Sep 2003 [EMAIL PROTECTED] wrote:
I want to compile gtkhtml2 (libgtkhtml) for windows,
I use MinGW (gcc-3.2.3) and cygwin.
My problem is that only static libraries are created
Bob Friesenhahn wrote:
On Thu, 25 Sep 2003, Bernhard Rumpler wrote:
When I try to link static libraries, then a warning Linking the shared
library libgtkhtml-2.la against a loadable module - libhtmllayouthtml.a is
not portable! is displayed. What does not portable mean in this
context?
I
Does anyone know why libtool uses 'strip --strip-debug' to strip static
libraries? ISTM that 'strip -x' (a.k.a. 'strip --discard-all') would be
more appropriate (i.e., makes the file smaller and the library still
works).
--
Peter Eisentraut [EMAIL PROTECTED
Es schrieb Dan Kegel:
Guido Draheim wrote:
... See - the libtool crossgcc support (to which I did
contribute some of the time) can simply ask the cross-gcc
for the local searchpath via `gcc -print-search-dirs` -
this is needed for win32 compiles atleast, and I have a
patch on my disk
Guido Draheim wrote:
... See - the libtool crossgcc support (to which I did
contribute some of the time) can simply ask the cross-gcc
for the local searchpath via `gcc -print-search-dirs` -
this is needed for win32 compiles atleast, and I have a
patch on my disk which generalizes the idea
I think this is my final real problem with the CVS version of libtool
(once Per's patch is applied).
Libtool isn't building static libraries for my project, although it does
try to install them (and fail).
Configuring with --disable-static is my work around.
Any ideas?
AG
On Fri, Mar 01, 2002 at 02:15:05PM -0800, Anthony Green wrote:
I think this is my final real problem with the CVS version of libtool
(once Per's patch is applied).
Libtool isn't building static libraries for my project, although it does
try to install them (and fail).
You need to be more
On Fri, 2002-03-01 at 15:32, Albert Chin wrote:
You need to be more specific
1 Does it fail while configuration your application to detect
that static libraries can be built?
I don't know what you mean exactly
2 For what compiler (C, C++, GCJ)?
GCJ (however, some of the libraries
On Mar 1, 2002, Anthony Green [EMAIL PROTECTED] wrote:
Libtool isn't building static libraries for my project, although it does
try to install them (and fail).
What's the exact failure mode (snipped of the make output)? What does
libtool --features print? What is in the .la file that it's
On Aug 13, 2000, Assar Westerlund [EMAIL PROTECTED] wrote:
* ltconfig.in: add back ranlib calls for static libraries if there
is a ranlib
Thanks, I'm checking this in. Sorry about the delay.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC
Hi Kevin,
On Thu, May 18, 2000 at 11:43:28PM -0400, Kevin Atkinson wrote:
On Thu, 18 May 2000, Ossama Othman wrote:
Sure. I don't know anything about libtool's internals but if you send me
a patch I can try it out on several different platforms including Digital
UNIX which currently doesn't
72 matches
Mail list logo
