I'm looking for a way to specify custom flags for the
"inherited_linker_flags" setting in my .la. It seems like I need this to
implement the semantics of gcc's weak references way I'd like them to work.
The scenario:
libx.la has a weak reference to symbol "Y".
liby.la declares the symbol "Y".
My source tree builds two libraries, from two separate directories in the
source tree.
libxtls.la gets linked against libx.la in a different directory, as well as
some system libraries in /usr/local/lib. Makefile.am declares thusly:
libxtls_la_LIBADD=../base/libx.la
libxtls_la_LDFLAGS=-vers
Gary V. Vaughan writes:
libltdlc.{a,la} is a convenience library - that is an ar(1) archive of
shared objects to be statically linked (copied) into a program directly. It
is never installed, but built from sources included in the distribution of
the parent package.
You should find that t
I have about a dozen libraries that get built with libtool. They're all
convenience libraries but they can be developed individually, so they have
their own configure script, as well as as all the libtool-related scripts.
These libraries are included in five major projects, in various
combinat
Bob Friesenhahn writes:
On Sat, 13 Jun 2009, Sam Varshavchik wrote:
Can anyone suggest a clean way to eliminate all those copies of ltmain.sh. I
can always hack up a hook that replaces them with hardlinks, before the
tarball gets created, but perhaps there's a better way. The catch he
I'm trying to come up with logic to figure out what I need to pass to
lt_dlopen(), or lt_dlopenext() in order to obtain the standard C runtime
library, for the purposes of using lt_dlsym() to find common library
functions, such as open(), connect(), etc…
I can use a prepared list of common nam
Howard Chu writes:
Running something in the configure script would work for me. Has anyone ever
did something like this? Such as, determining that lt_dlopenext() ends up
really opening "libc.so.6", so that's what I really need to open?
None of this guesswork should be needed. Since the main pr
Ralf Wildenhues writes:
* Sam Varshavchik wrote on Sun, Dec 06, 2009 at 02:52:52PM CET:
My use case is intercepting a main application's calls to library
functions. I set LD_PRELOAD to preload my own shared library which
provides replacement symbols for socket(), connect(), etc…
What
Simon Richter writes:
Hi,
On Sun, Dec 06, 2009 at 08:52:52AM -0500, Sam Varshavchik wrote:
My wrapper needs to find the real socket() and connect(). I haven't
checked this yet, but I suspect that since my shared library was
loaded ahead of libc, after lt_dlopen(NULL), using lt_dlsym()
I'm trying to do the following with libtool, and it's not quite doing
exactly what I want. Can someone suggest the correct way to do the
following, with libtool 1.5.6 and automake 1.8.3 on Linux:
I'm building several shared libraries. These shared libraries use common
code from several static
Simon Richter writes:
Hi,
My intentions here are:
Build the sources for libauthuserdb.la. Take their object code, and grab
whatever modules from libauth.la that are references by stuff in
libauthuserdb.la, and place all of that into a shared library.
Not possible without reimplementing parts of
I've almost tracked down the source of random link-install failures that
unexpectedly blows up a long build cycle.
I'm using libtool 1.5.6 with automake 1.8.3 on Linux. I'm building a fairly
extensive app that installs a bunch of shared libraries and executables.
And it uses a bunch of conven
Bob Friesenhahn writes:
So I was forced to read through a long (and well written) email before
the crux of the matter appeared. If make should not be running these
targets in parallel then this smells like an Automake problem to me.
No, from automake's perspective there are no dependencies betw
13 matches
Mail list logo
