[Bioc-devel] GSVA/configure.ac problem

[Dan Tenenbaum]

Hi all,


2011/11/11 Robert Castelo <robert.castelo at upf.edu>:
> hi Hervé,
>
>> Yes "the core development of BioC" (and in that case it was me) fixed
>> the configure script a couple of days before the release because it was
>> not working properly on our Mac OS X build machine. I must confess I'm
>> not an expert with configure scripts either so what I did was copy
>> the configure.ac file from another package that links to the GSL, and
>> did very minor modifications to it (if you do diff GSVA/configure.ac
>> flowClust/configure.ac you'll be surprised how little different those
>> files are). I forgot to replace >= 1.6 by >= 1.12 though, sorry.
>
> thanks a lot for fixing the configure script. I have found out in the
> last days that in fact this "1.6" version might have to do with the
> versioning standard of GSL for windows which according to this url:
>
> http://gnuwin32.sourceforge.net/packages/gsl.htm
>
> seems to follow an independent scale since it says that right now the
> latest version is "1.8". so i've made the change in the devel-version of
> GSVA but i'm afraid that it may not build anymore in windows. In such a
> case I guess I would have to address that by updating the configure.ac
> script such that if the system is unix then requires version >= 1.12 and
> if it's windows then it requires version >= 1.6. I hope I don't have to
> because at the moment I have no clue how I would do that.
>
> next to this, in a recent post at BioC
>
> https://stat.ethz.ch/pipermail/bioconductor/2011-November/042033.html
>
> it was described an additional step that should be done to have a
> successful windows installation of the GLAD package, which also requires
> GSL, and which consists of duplicating the file libgsl.dll into a file
> called libgsl-0.dll
>
> i have verified in the windows xp partition of my mac, that this latter
> step is absolutely necessary to have an installation of GSVA, and GLAD
> too, without problems. so i wonder whether you had to do the same with
> the GSL installation of your windows machines in Seattle, or you install
> GSL in windows in some other way.

I can't say exactly where we got the GSL on our build machines. We
must have downloaded it at some point and I'm trying to find that
download, but so far without luck. I believe that we downloaded a
pre-compiled version of GSL for windows.

I can tell you that the version of GSL we are running on our windows
build machines is 1.13.

I don't think we copied libgsl.dll to libgsl-0.dll. In fact, in our
distribution of the GSL there is no libgsl.dll, only libgsl-0.dll, and
you can see by looking at the build reports that GSVA, GLAD, and other
packages using the GSL are building fine.

There are a couple of other things you need to do:
1) Set an environment variable called LIB_GSL that points to the root
of your GSL installation (on our build machines, C:/GSL (note forward
slash).
2) Make sure c:\GSL\i386\bin and c:\GSL\x64\bin are in your PATH.

Hope this helps,
Dan


>
>> That seems to work (I just tested this on my Linux laptop). Don't
>> forget to rerun autoconf.
>
> thanks, i've done just that and submitted the changes to devel. if i see
> that the package builds and installs correctly i'll push them to
> release.
>
>> Even for a non system-wide installation of GSL, the user can always
>> (and should) have the gsl-config script in his/her PATH. It's reasonable
>> to assume that if s/he was able to install his/her own private GSL, s/he
>> also knows how to modify his/her PATH to point to it. Alternatively, as
>> displayed by the error message above, s/he can set the environment
>> variable GSL_CONFIG to point to his/her private copy of
>> gsl-config. Does that make sense?
>
> yes, you're right, thanks for clearing this up. I've also updated
> accordingly the README file of the package.
>
>
> cheers,
> robert.
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>