Bob Friesenhahn wrote:
On Fri, 17 Aug 2007, Jason Curl wrote:
I have a system that supports shared libraries (Solaris 9). As part
of some checks for 'getopt_long' I check if it exists in 'libiberty'
if I can't find it in the standard system. It's there in libiberty.
Now the problem occurs because there's only "libiberty.a" and no
"libiberty.so.x.y.z" file.
Shouldn't AC_CHECK_LIB support shared/static libraries too? Or should
libtool see that there's no shared library and statically link it
somehow into my library that will become shared?
When libiberty is installed, it does not also install the .la file
necessary for libtool to know that the library is static, and where to
find the static library.
Perhaps the authors of libiberty do not expect that it will be used by
anyone else.
Then this condition needs to be testable. I see two options:
- Automatically disable shared libraries on this platform
- Link statically from this library to our shared library
There is no .la for this of course, I don't think it can be expected for
it to be installed just for the sake of libtool. Almost every library on
my system does not have the corresponding .la. Shouldn't libtool notice
it is missing and try to deduce from naming conventions at least on sane
systems what the situation is?
As for testing the situation, AC_CHECK_LIB makes me believe it will
work. But it only works in a subset of cases (i.e. static only). I have
another implementation that I can compile in but at the moment there is
no indication I should use my own internal implementation (I'd rather
use an external implementation where possible in the belief it's
probably been better debugged).
So, ideas how to work around this problem to achieve my goal?
Thanks,
Jason.
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
