Miguel,
these kind of problems made me lose a lot of time. On Mac I think the correct
strategy is not to rely on ANY preinstalled library and make his own local
developement environment. Recompiling all the libraries needed by TeXmacs can
take at most half an hour on a modern machine and saves a lot of time fighting
with incompatible versioning.
I've set up a complete developement environment in misc/tm-devel-mac with
packages for all the software needed by texmacs. There is a configure-tm file
which can be easily hacked to call configure with all the right paths and
dependencies once the environment is set up. I can have the control on the Qt
flags and have guile linked statically in the source. In any case system
libraries are a no opt if you are creating a bundle and you want it to be
robust.
By similar reasons in my opinion this should be the way things have to be done
on Windows too.
For Unix machines one should rely on system libraries so have two versions of
the same library installed should be considered not the common thing.
An option of course can also be to change all the configure to allow for exact
paths of libraries but this will not solve the problem since you cannot ensure
that a library which you call uses another copy of a library which you have
linked in manually (for example think about guile and TeXmacs using different
copies of gmp or libz, etc...).
So I think the easiest way to have a complete control of libraries (on Mac and
Windows) is to recompile them locally with strict control of the building
environment.
Best,
Max
On Oct 13, 2013, at 10:13 PM, Miguel de Benito Delgado <m.debenit...@gmail.com>
wrote:
> 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
_______________________________________________
Texmacs-dev mailing list
Texmacs-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/texmacs-dev
