texmacs-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Texmacs-dev] Linking against one of multiple installed libraries


From: Miguel de Benito Delgado
Subject: [Texmacs-dev] Linking against one of multiple installed libraries
Date: Sun, 13 Oct 2013 22:13:39 +0200

Hi,

  compiling the sources may fail if for some reason several versions of the same library are present. Although the problem is NOT operating system specfific, this happens in particular for the stock libiconv in MacOS 10.7 and the latest one in MacPorts.

  Imagine I need to link TeXmacs against some library libfoo installed in /opt/local, where I happen to also have some version of libiconv. The configure process adds 

     -L/opt/local/lib -lfoo -liconv 

to the link line: the linker adds /opt/local/lib to the search paths, coming before the standard /usr/lib. It then tries to link against /opt/local/lib/libiconv.dylib and fails because the version is not the one needed. We want /usr/lib/libiconv.dylib.

A workaround is to put -liconv first in the line. But this is pretty flaky as a fix.

I see no workaround other than specifying the full library as another object to the linker instead of using -L and -l, but this is ugly: we have to expand the -L and -l and append an appropriate extension depending on the operating system: .so, .dylib, .lib, .a ...

See for instance a hack fixing the configure.in for libiconv (note the case "${host}")

    if test -n "$ICONV_CFLAGS" -a -n "$ICONV_LDFLAGS"; then
       CPPFLAGS="$ICONV_CFLAGS"
       LDFLAGS="$ICONV_LDFLAGS"
    fi
    if test "$with_iconv" != "yes" -a "$with_iconv" != "" ; then
       CPPFLAGS="-I$with_iconv/include"
       case "${host}" in
          *mingw*) _EXT="lib" ;;
          *apple*darwin*) _EXT="dylib" ;;
          *) _EXT="so" ;;
       esac
       LDFLAGS="${with_iconv}/lib/libiconv.${_EXT}"
    fi

    AC_CHECK_HEADER(iconv.h,
    AC_MSG_CHECKING(for iconv)
    AC_TRY_LINK(
    ... blah blah

then later at some point:

      ICONV_CFLAGS="${CPPFLAGS}"
      ICONV_LDFLAGS="${LDFLAGS}"

In general, one would like a configure option --with-foo-library=/some/path to enforce linking against that particular library without screwing the rest of the linking, but the use of -L/some/path *does not* ensure this. As explained, there may be other versions of libfoo in other -Lpaths. Also, there we might need some libwhatever which should be taken from a standard path but which might not be anymore if it is in /some/path too.

I know this is a lot to read and that the problem isn't worth that much time. But if anyone has made it this far... Any ideas?

Best,
--
Miguel de  Benito.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]