Hello Joakim,
* Joakim Tjernlund wrote on Sun, Dec 06, 2009 at 08:47:00PM CET:
>
> what do I write in Makefile.am to make libtool build dyn libs only?
> It seems like libtool always wants to build both static and dyn libs
> but I want to build some libs dynamic only to save build time/space.
lib
what do I write in Makefile.am to make libtool build dyn libs only?
It seems like libtool always wants to build both static and dyn libs
but I want to build some libs dynamic only to save build time/space.
Jocke
___
http://lists.gnu.org/mailman/list
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() will
si
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 level o
* 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 level of portability do you
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
* Howard Chu wrote on Sun, Dec 06, 2009 at 05:39:02AM CET:
> Sam Varshavchik wrote:
> >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 li