test [in configure] whether libs can be used to create shared libyat

[Peter]

spinn off from #733

To solve problems reported in ticket #733 we should detect whether shared library is available or only static one, i.e., -lfoo falls back on libfoo.a.

We should only add -lfoo to yat_libyat_la_LIBADD when there is a shared version of -lfoo available. Except that we do not want to hard-code CBLAS into libyat.so as discussed in README.

To differentiate between whether shared library or only static one is available, we need to do link tests using libtool (see YAT_LT_LINK_IFELSE)

[Jari Häkkinen]

Static libraries are also used so the test should be whether the underlying library is usable. If a static library fails the test configure should suggest to recompile the failing library with -fPIC.

[Peter]

I was probably unclear. I suggest that the test should find out whether 1) shared libfoo available, or 2) only static libfoo available, or 3) no libfoo available. These three cases can be identified by doing two tests. First a) check if we can create a shared libbar that links against -lfoo; if that fails b) check if we can link against -lfoo (as now).

Now we have three different outcomes and we can run configure with three different configurations: --disable-static, --disable-shared, or default (both enabled if supported by system), which gives nine different combinations.

1. If -lfoo not available, we barf just like now.

2. If shared is disabled, we add -lfoo to yat_libyat_la_LIBADD because we want -lfoo to be mentioned in libyat.la. Actually, when shared is disabled, we don't care if -lfoo is shared or static and don't need to perform test a).

3. If shared is enabled and shared libfoo is available, we add -lfoo to yat_libyat_la_LIBADD so -lfoo is included into header of libyat.so and so that -lfoo is included into libyat.la.

4. Lastly, if only static libfoo is available and shared is enabled, we do not add -lfoo to yat_libyat_la_LIBADD but obviously we must add it when linking binaries in tests as well as adding it in yat-config and yat.pc.

Note that yat_libyat_la_LIBADD is not used when creating libyat.a, i.e., running libtool with --static. Also, the only case that is changed compared with current behavious is 4), which currently fails to build (as reported in ticket #733).

[Jari Häkkinen]

Replying to peter:

4. Lastly, if only static libfoo is available and shared is enabled, we do not add -lfoo to yat_libyat_la_LIBADD but obviously we must add it when linking binaries in tests as well as adding it in yat-config and yat.pc.

My comment above relates to this case. Static only libfoo is useful if compiled properly (with -fPIC) even for shared libyat. I think the test should check whether the static library is useful with shared libyat not discard it solely based on the fact it is static.

[Peter]

Replying to jari:

My comment above relates to this case. Static only libfoo is useful if compiled properly (with -fPIC) even for shared libyat. I think the test should check whether the static library is useful with shared libyat not discard it solely based on the fact it is static.

OK, now I get your point, and I agree. Actually, when I said "find out whether 1) shared libfoo available" I meant: test whether we can create a shared libbar that links to -lfoo (I thought those statements were the same, but according to you they're not). So replace "having a shared libfoo" in scheme above with "having a libfoo that can be linked into a shared libbar".

[Peter]

Ticket #745 referred to this ticket.

[Peter]

When implementing this I will also change so configure is aborted when missing fatal error is detected such as missing library. It makes it easier to understand the output as the abortion is caused by the most recent test executed. Also it makes it easier to find the relevant tests in the log file (as they are in the bottom). Only argument I've heard against it is that it is nice to find out all error/requirements getting one, fix it, get the next one etc. I think, however, that users can still read the README if they wanna know about requirements. In fact, reading the README is recommended and catering for users who don't - I don't know.

[Peter]

(In [3072]) prefer aborting directly when error is detected rather than in the end. refs #737

[Peter]

(In [3086]) add a new variable YAT_STATIC_LIBS; perform test if LIBM is suitable for libyat.la or should be added to YAT_STATIC_LIBS. refs #737

[Peter]

(In [3087]) refs #737. check if -lgsl is suitable for libtool archive

[Peter]

(In [3088]) avoid repetetive code and add tests for boost libs. refs #737

[Peter]

(In [3091]) add test for libz and libbam. refs #737

[Peter]

(In [3110]) Fix test of YAT_LT_LINK_IFELSE. The macro/linking worked also against static library, which is unexpected. When I modified to an library with more symbols (libyat) I get the error: "relocation..." as expected. refs #737.

configure.ac: AC_SUBST lt_vc_objdir from libtool test/defs.sh.in: define dito test/gen_libmy_static.sh: copy libyat.a rather than creating a small libmy-static.a from scratch. yat_lt_link_la_ifelse_test.sh: link against theplu::yat::utility::version(void) as libmy-static now just is a alias for libyat.

[Peter]

(In [3111]) refs #737

configure.ac: Define new variables YAT_LIBS, YAT_STATIC_LIBS, yat_libyat_la_LIBADD, YAT_PRIMARY_LIBS, and YAT_PC_LIBS (see code for definitions).

build_support/yat.pc.in: reflect new variables build_support/yat-config.in: reflect new variables build_support/gen_yat_pc.sh.in: reflect new variables build_support/Makefile.am: reflect new variables yat/Makefile.am: use AC_SUBSTed yat_libyat_la_LIBADD test/static_test.sh: avoid redeclaring variable in generated Makefile.am

[Peter]

This ticket is in principle implemented. One big headache left though: I found that ./configure --disable-static does not work. It barfs out on the first compiler test (after YAT_USE_LIBTOOL_PUSH) complaining it can't compile 'gsl/gsl_version.h'.

[Peter]

Alright so the problem is that the compiler test check that there is an output conftest.o, but when libtool compiling in only-shared-mode libtool only creates a conftest.lo (and .libs/conftest.o).

[Peter]

(In [3113]) change YAT_USE_LIBTOOL_[PUSH|POP] so it only affects the linking tests and *no longer* the compilation tests. closes #737