Hello Bob,
thank you for your answer.
On Thu, Nov 12, 2009 at 10:50:03AM -0600, Bob Friesenhahn wrote:
> On Thu, 12 Nov 2009, Stepan Kasal wrote:
>>
>> Is there an option that would tell libtool to "build both", even
>> though it was configured with --disable-static?
>>
>> I invented a solution that should work: configure with
>> --enable-static and then use -shared in CFLAGS or AM_CFLAGS for all
>> but libraries but that one. I could recommend this solution to the
>> user, but I feel that the solution outlined above would be more
>> comfortable.
>
> This is the solution which currently does work, as long as the OS,
> tools, and libraries are capable of it. Note that using
> --disable-static is not portable so attempting to force only a shared
> build decreases portability. [...]
I understand that building shared library only is something that is
not portable, because it is not possible.
> You may encounter similar issues on Unix system if
> there is dependence on an installed library which does not have a shared
> version available.
This is a twofold example. When building a package for a GNU/Linux
distribution, the --disable-static behaviour is always desirable.
If a build of shared library fails, it is always necessary to fix the
build environment so that dynamic linking is possible. It would be
really evil if the build silently falled back to static linking.
Anyway, back to the problem:
Though the original reporter probably does not care, the solution
should not compromise portability of the generated tarball. From
that point of view, it is not desirable to set AM_CFLAGS=-shared in
most subdirs of the project. It is better to override CFLAGS at
build time.
But the dreamed of solution would still be better, even from the
portability angle:
The library that needs to be built also as static one, say libfoo,
would have:
libfoo_la_CFLAGS = -static-and-shared
With that, even if the project were configured as --disable-static,
this one library would fall back to the previous default, which is to
build both staic and shared if possible.
Would it make sense to add this type of option to libtool?
Or is it more consistent to keep things as they are and shoft the
problem to the user, so that README would instruct him how to
manipulate CFLAGS during the build?
Actually is it wise to try to encode this static/shared combination
into the tarball? Can it be understood as a property of the package
(libfoo is a compatibility one, should be available as static lib on
most platforms), or is it a platform specific issue, so that shifting
the problem to the user of the tarball is the right thing to do?
Happy hacking,
Stepan
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
