Opened 8 years ago

Closed 8 years ago

#737 closed enhancement (fixed)

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

Reported by: Peter Owned by: Peter
Priority: major Milestone: yat 0.11
Component: build Version: 0.10
Keywords: Cc:

Description

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)

Change History (19)

comment:1 Changed 8 years ago by 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.

comment:2 Changed 8 years ago by 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.
  1. 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).
  1. 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.
  1. 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).

comment:3 in reply to:  2 ; Changed 8 years ago by Jari Häkkinen

Replying to peter:

  1. 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.

comment:4 in reply to:  3 Changed 8 years ago by 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".

comment:5 Changed 8 years ago by Peter

Summary: detect whether shared lib is available in configure testsdetect whether libs can be used to create shared libyat in configure tests

comment:6 Changed 8 years ago by Peter

Ticket #745 referred to this ticket.

comment:7 Changed 8 years ago by Peter

Status: newassigned

comment:8 Changed 8 years ago by 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.

comment:9 Changed 8 years ago by Peter

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

comment:10 Changed 8 years ago by Peter

Summary: detect whether libs can be used to create shared libyat in configure teststest [in configure] whether libs can be used to create shared libyat

comment:11 Changed 8 years ago by 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

comment:12 Changed 8 years ago by Peter

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

comment:13 Changed 8 years ago by Peter

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

comment:14 Changed 8 years ago by Peter

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

comment:15 Changed 8 years ago by 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.

comment:16 Changed 8 years ago by 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

comment:17 Changed 8 years ago by 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'.

comment:18 Changed 8 years ago by 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).

comment:19 Changed 8 years ago by Peter

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.