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.
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev

Reply via email to