[Rd] libtool FIXME

[Kurt Hornik]

>>>>> Marco atzeri writes:

> Hi,
> looking on the build scripts, I noticed on configure.ac

> ## <FIXME>
> ## Completely disable using libtool for building shlibs until libtool
> ## fully supports Fortran and C++.
> ## AC_ARG_WITH([libtool],
> ## [AS_HELP_STRING([--with-libtool],[use libtool for building shared 
> libraries @
> <:@yes@:>@])],
> ## [use_libtool="${withval}"],
> ## [use_libtool=yes])
> ## AM_CONDITIONAL(USE_LIBTOOL, [test "x${use_libtool}" = xyes])
> ## </FIXME>

> Is this comment outdated or still valid ?

Marco,

svn blame has

 17895     hornik ## Completely disable using libtool for building shlibs until libtool
 17895     hornik ## Completely disable using libtool for building shlibs until libtool

and change set 17895 is from 2002-01-21, so almost 10 years old.

Then it was certainly true.  Whether it still is, I don't know: we
needed to put considerable effort into creating our own non-libtool
solution.  Now we have something working and considerable effort would
be needed to rewrite the build toolchain [and I'd additionally be
concerned about possible future lack of libtool support for things R
needs to support].

Best
-k

> In my experience, Octave, that is mainly Fortran and C++ plus a small
> amount of C, is fully employing libtool and automake with a very clean
> and lean build system.

> My question is not just academic; I was thinking to package
> R for cygwin but the current configuration produce shared libs
> with the wrong name

>    /usr/bin/libR.dll
>    /usr/bin/libRmath.dll

> instead of expected

>    /usr/bin/cygR.dll
>    /usr/bin/cygRmath.dll

> (http://cygwin.com/cygwin-ug-net/dll.html#dll-build)
> so the "as it is" package will be rejected and a substantial
> patching of the various "Makefile.in" will be needed to make
> it conformant.


> Thanks in advance
> Marco

> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel