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 don
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 make
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 hav
$ 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
CoreFoundat
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 t
you get this message twice):
From: Vadim Zeitlin
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 but th
e 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,
*** 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 app
*** 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 ap
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:
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
/usr/i486-mingw
Unfortunately nobody seems to be here who works with Libtool under cygwin and
could help me.
In the meantime I have found the solution for my question.
Libtool 2.2.6 does not work proper under cygwin.
It is to be installed Libtool 2.2.7. And everything runs perfectly.
--
Jetzt kostenlos herunterl
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
--
on cygwin I had modified the Makefile.am hello example as follows:
lib_LTLIBRARIES = libhello.la
libhello_la_SOURCES = hello.c
libhello_la_LDFLAGS = -no-undefined -avoid-version -lmingw32
but this results in:
*** Warning: linker path does not have real file for library -lmingw32.
*** I have
On Sun, 28 Jun 2009, Charles Wilson wrote:
Interesting. I think that it is assumed that "PIC" code will work in a
static archive. Apparently this is a wrong assumption for "decorated"
DLL code. Most open source projects ported to Windows rely on GCC's
automatic DLL import feature.
Unless yo
Bob Friesenhahn wrote:
> 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,
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 contai
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
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 (filemagi
* 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)
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 "x8
On Fri, 27 Feb 2009, 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
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 imp
* 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 w
> 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
___
http://lis
"[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 he
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
>(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 name
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
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 inc
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, autocon
/www.gnu.org/software/libtool/manual.html#Static-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 p
ly for libtool:
> >http://www.gnu.org/software/libtool/manual.html#Static-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 bui
, 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 "n
; checking whether to build shared libraries... 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 ?
why do you
" 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
On Tue, Apr 11, 2006 at 09:07:49PM -, [EMAIL PROTECTED] wrote:
> I would like compile a shared library of PHP for loading it into apache on
> the HP-UX os.
>
> The problem is that i cannot because :
>
> - one of the different libraries used by php for
> compiling is c-client (im
there's no easy way to guarantee that requirement with
static libraries.
- Is there a way to resolve this situation ?
Manually build c-client as a shared library, or build c-client so that
all object files are compiled as PIC and then hack libtool so that the
checks for static librari
Hello,
I would like compile a shared library of PHP for loading it into apache on
the HP-UX os.
The problem is that i cannot because :
- one of the different libraries used by php for
compiling is c-client (imap) who is only
available as a static library.
-
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
nt used for the open source 3D engine Crystal Space, but now
I have decided to try using automake so forgive my mistakes in the
usage of automake.
Anyhow, regardless of whether or not how I was attempting to achieve
library renaming is valid or not, I still have the same problem in
that I wish to
On Thu, Feb 16, 2006 at 03:55:44PM +0100, Alexandre Duret-Lutz wrote:
> Take the string "[EMAIL PROTECTED]@.la" (that's what
> Automake reads). To canonize it, replace characters that are neither
I meant to write "canonicalize". The above mistake should not be
regarded as a caricature of any rel
On Thu, Feb 16, 2006 at 04:22:24PM +1100, Brendon Costa wrote:
>
> The configure script exports the following two variables for use in
> automake that help with versioning:
>
> PACKAGE_VERSION 1.0.6
> PACKAGE_VERSION_UNDERSCORE 1_0_6
>
Sorry, that makes no sense : the substitutions a
tch between the
version used for the install file names and the version numbers used
in the compiled code.
I was hoping that I could use the -release option to do this and was
very surprised that the functionality was not consistent for both
dynamic and static libraries.
>
> The other alternati
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
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
Hi Eric,
* Eric Lemings wrote on Wed, Feb 08, 2006 at 08:57:07PM CET:
>
> How do I configure and run the libtool script so that when it
> is creating a static library that it links or embeds any
> dependent static libraries directly into the newly created
> static library?
Curre
Hello,
How do I configure and run the libtool script so that when it
is creating a static library that it links or embeds any
dependent static libraries directly into the newly created
static library?
Thanks,
Eric.
___
http://lists.gnu.org/mailman
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 *.o
I am listening, and I have ta
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 th
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
and
f 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 me
de from several 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
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 libh
ed very good arguments
|>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
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 s
in the form suitable for
the compiler command line), 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.
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 - libhtmllayou
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 bo
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
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.
> > >
> > >
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.
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:
> 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.
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 libto
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,
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
(sta
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 l
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) tha
[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
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
Hello,
I'm trying to build a static library. I can make a shared library and I
can use this library with
g77 -o example example.o -lrpl
without any trouble. But, if I try to use the generated static library with
g77 -o example example.o /usr/local/lib/example
some symbols are
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
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
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 ide
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 i
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 (how
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 (a
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
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.unic
It seems to me that -current libtool has lost the ability to run
ranlib when creating static libraries. I added back the lines from a
previous versions, see patch at end. Is there any reason for not
calling ranlib? Not using ranlib does make static libraries not work
on some platforms, for
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 does
On Thu, 18 May 2000, Ossama Othman wrote:
> > I was wondering what the status of:
> >
> > 1) Adding support for C++ on all (or most) platforms where g++ is used
> > as the C++ compiler.
>
> The problem with the C++ support in the multi-language branch in the
> case of g++ is that each platform
Hi again,
Okay, I'm too tired to speak properly.
On Thu, May 18, 2000 at 07:46:23PM -0700, Ossama Othman wrote:
> Does this reasonable?
I meant "does this sound reasonable?"
-Ossama
--
Ossama Othman <[EMAIL PROTECTED]>
Distributed Object Computing Laboratory, Univ. of California at Irvine
102
Hi Kevin,
Sorry that I haven't been moving on this stuff. I've been busy with
the work that feeds me. :-)
On Thu, May 18, 2000 at 09:26:28PM -0400, Kevin Atkinson wrote:
> About a month ago we discussed better C++ support and support for dropping
> static libraries not compil
About a month ago we discussed better C++ support and support for dropping
static libraries not compiled with PIC code when creating shared
libraries.
I was wondering what the status of:
1) Adding support for C++ on all (or most) platforms where g++ is used
as the C++ compiler.
2) Adding
On Sat, Mar 25, 2000 at 05:16:52PM -0300, Alexandre Oliva wrote:
> On Mar 25, 2000, Jason Day <[EMAIL PROTECTED]> wrote:
>
> > This is what I'll do then. Maybe this could be a future enhancement to
> > libtool?
>
> Libtool can't do that in general, since it cannot assume an archive
> contains P
On Mar 25, 2000, Jason Day <[EMAIL PROTECTED]> wrote:
> This is what I'll do then. Maybe this could be a future enhancement to
> libtool?
Libtool can't do that in general, since it cannot assume an archive
contains PIC code. However, this gives me an idea: we could have some
mechanism to creat
de available a
> > plugin library (static, but pic), which I link with my code to build
> > the plugin. This works fine using gcc on linux, but I can't get
> > libtool to do it. Can libtool do this?
>
> Ah, okay I see what you mean now. And I'm afraid that the answer
able a
> plugin library (static, but pic), which I link with my code to build
> the plugin. This works fine using gcc on linux, but I can't get
> libtool to do it. Can libtool do this?
Ah, okay I see what you mean now. And I'm afraid that the answer is
"sort of",
Sorry, forgot to CC the list.
-- Forwarded Message: -
From:[EMAIL PROTECTED]
To: "Gary V. Vaughan" <[EMAIL PROTECTED]>
Subject: Re: Linking static libraries into shared library
Date:Fri, 24 Mar 2000 15:59:50 +
> On T
On Thu, Mar 23, 2000 at 09:12:54PM -0500, Jason Day wrote:
> On Fri, Mar 24, 2000 at 12:43:24AM +, Gary V. Vaughan wrote:
> > On Thu, Mar 23, 2000 at 05:38:35PM -0500, Jason Day wrote:
> > > So I tried building a shared version of the static library, and libtool gave
> > > me a shared library,
On Fri, Mar 24, 2000 at 12:43:24AM +, Gary V. Vaughan wrote:
> On Thu, Mar 23, 2000 at 05:38:35PM -0500, Jason Day wrote:
> > So I tried building a shared version of the static library, and libtool gave
> > me a shared library, but with a dependency I didn't want. Is there a way to
> > link a
On Thu, Mar 23, 2000 at 05:38:35PM -0500, Jason Day wrote:
> So I tried building a shared version of the static library, and libtool gave
> me a shared library, but with a dependency I didn't want. Is there a way to
> link an object file and a (PIC) static library into a self-contained shared
> l
I'm trying to link an object file and a static library together into a
shared library. I've been doing this with gcc without problems, but now I'd
like to use libtool for more portability. Linking the files with libtool,
however, gives me something like this:
*** Warning: This library needs som
95 matches
Mail list logo
