Ralf Wildenhues wrote:
Hi Vlad,
* Vlad Skvortsov wrote on Fri, Dec 09, 2005 at 11:46:46PM CET:
Ok, I believe I have to explain more here. My product is deemed to be
self-contained: no dependencies on external shared libraries, nothing. I
build all my [C] applications static. However, recently a need has
arised to write a Perl script and include it into the distribution. This
script needs some functionality from my core libraries. So I have to
build a shared module that my Perl script will load and use. I guarantee
that noone else will link against this shared module; if someone will,
it's not my problems, since I didn't intend to.
My application uses third-party library that is [deemed by its author to
be] built as shared. However, I want all my applications to link
statically against it and I want my shared module to include its
contents (so that the end user doesn't have to install this third-party
shared library).
Does it make the situation clearer?
Yes. The answer is: I don't think this is possible. This isn't even a
limitation of the autotools, but simply a limitation of most systems:
you can't portably get a shared library to end up being contained in an
archive, and the result be used correctly. Somebody please correct me
if I'm wrong here, but I would not know that this is doable. The only
exceptions I know where this *may* work are w32 and AIX, actually only
the latter I believe.
Well, yes, I understand that it's not possible if all we have is just a
shared library binary. But my case is when I have _sources_ of the
libtool-controlled library, not in my tree though. So, I have both .a
and .so/.dylib for that. The one thing that is missing here is the
ability to make autotools use the right file.
--
Vlad Skvortsov, [EMAIL PROTECTED], [EMAIL PROTECTED]
