Well,
I do realize that it's non-portable, but the number of platforms I'm
building on is very restricted (the application is only of any real use
on Linux systems running RPM, dpkg, and a few other special cases). I'm
not really intentionally trying to use libtool; I'm just using automake,
Ian:
Automake uses Libtool to create libraries because it is portable,
it's practially the only thing that is. One thing you should check,
do you really have to specify what is static? I belive that under
Linux, the linker will choose shared libs over archives, if that
helps at all. Perhaps
Ian Peters writes:
Yes, the end goal is to have all of the libraries between the -Bstatic
and -Bdynamic linked statically, while keeping a dynamic binary against
libc and ld-linux.
You do realize that this goal cannot be portably accomplished, so you
perhaps shouldn't use libtool?
--
Peter
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote:
On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote:
Conspicuously missing are the linker directives to be passed to gcc,
namely -Wl,-Bstatic and -Wl,-Bdynamic. I do this to produce a binary
that is linked statically except for
On Fri, 2001-10-05 at 02:19, [EMAIL PROTECTED] wrote:
What's bad is their position has been reordered. What version of
libtool are you using? I take it you want all libraries between
-Bstatic and -Bdynamic statically linked?
Forgot to say, this has been tested with libtool 1.4 and 1.4.2.
--
On Fri, 2001-10-05 at 02:21, Tim Van Holder wrote:
On Fri, 2001-10-05 at 07:14, Ian Peters wrote:
Unfortunately, with libtool 1.4.x, I get this instead (after a much,
much longer time):
gcc -g -O2 -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -o
[snip]
installer-ui.o
On Fri, Oct 05, 2001 at 01:14:52AM -0400, Ian Peters wrote:
An application I work on has been calling libtool (through automake)
with linker directives on the libtool line, around many of the libraries
specified, like so (apologies if this wraps strangely, it's all one
line):
/bin/sh
