Hi Ralf,
On 2/6/2010 9:32 AM, Ralf Wildenhues wrote:
Hello,
to round up a couple of minor bits here:
* John Calcote wrote on Wed, Feb 03, 2010 at 05:57:49PM CET:
The trouble with LIBRARIES is that it only builds non-PIC static
libraries, which can't be linked into a libtool shared library
Hello,
to round up a couple of minor bits here:
* John Calcote wrote on Wed, Feb 03, 2010 at 05:57:49PM CET:
> The trouble with LIBRARIES is that it only builds non-PIC static
> libraries, which can't be linked into a libtool shared library. My
> example has a couple of minor flaws that I realize
On Wed, Feb 3, 2010 at 7:50 PM, Bob Friesenhahn
wrote:
> Since 9/11, 'hope' is not sufficient protection in today's world.
>
> Not all systems are capable of producing a 'partial' library, leaving some
> symbols unresolved and without knowing where the symbols will come from.
> Systems which come
On Wed, 3 Feb 2010, Justin Seyster wrote:
My hope is that this approach will protect users of the framework from
the most possible hidden linking danger.
Since 9/11, 'hope' is not sufficient protection in today's world.
Not all systems are capable of producing a 'partial' library, leaving
so
Thanks, this advice gives me exactly what I asked for (even if it
turns out that's not what I really wanted :-).
I agree entirely that putting the framework into the main program is a
good solution, but I'm not involved with the main program's
development, so that's not an option for me.
Right no
Steffan,
On 2/3/2010 5:50 AM, Steffen Dettmer wrote:
On Wed, Feb 3, 2010 at 8:33 AM, John Calcote wrote:
(PIC-based static only) library is to use the "noinst" prefix. But libtool
can be used to manually install a convenience library, so you could use
libtool to do this in an install-exec-
On Wed, 3 Feb 2010, Andrew W. Nosenko wrote:
Therefore, the safest way is to link your "framework" into main
process (and only into main process) and let the main process to
provide these "framework" functions to the modules loaded by him.
I find it convenient to have loadable modules depend o
On Wed, Feb 3, 2010 at 8:33 AM, John Calcote wrote:
> (PIC-based static only) library is to use the "noinst" prefix. But libtool
> can be used to manually install a convenience library, so you could use
> libtool to do this in an install-exec-local rule in the Makefile.am file
> that builds (for i
On Wed, Feb 3, 2010 at 03:39, Justin Seyster wrote:
> I'm working on a support framework for plug-ins, and I'm struggling to
> come up with a way to compile it. I'm leaning towards building it as
> a convenience library, but there a few SNAFUs.
>
> Each plug-in is itself a shared library. I woul
Hi Justin,
On 2/2/2010 6:39 PM, Justin Seyster wrote:
I'm pretty sure that making the framework a convenience library is my
ideal solution: the plug-in author will be able to distribute a single
shared object without any non-standard dependencies. However, I read
that Automake does not allow i
I'm working on a support framework for plug-ins, and I'm struggling to
come up with a way to compile it. I'm leaning towards building it as
a convenience library, but there a few SNAFUs.
Each plug-in is itself a shared library. I would like to avoid having
a second shared library that the plug-i
11 matches
Mail list logo
