getting a GDL dev version which compiles

  • Daniel Molina

    Daniel Molina - 2012-02-18


    I often download a dev version of GDL that doesn't compile correctly. However, there is important new code that I want to use, although probably I don't know which is it exactly. Which is the better way of having a compiling installation of GDL and having the bigger amount of dev improvements?


  • Sylwester Arabas


    Well, if any version does not compile correctly, it is a bug - please try to fix it, and then report either the fix or a description of the problem. Getting such feedback from our "power-users" helps us a lot!


  • Alain C.

    Alain C. - 2012-02-21


    You are really unlucky

    I make full end-to-end tests (on fresh copy of a CVS update, from "autoreconf -fi" to "make check")
    on various OS (debian, ubuntu, centOS, OSX …) several times a week, without significant problems.
    (when a file is missing or a problem created, we exchange and solve it in less that 24h. This happen less than a day in a month)

    Today, only 3 to 5 tests fail in testsuite, due to specific pbs on given OS/CPU (memory on Linux 64b, sem, ce). This is normal.

    If you have really a specific OS or CPU, maybe we have to consider it more carefully.


  • Mark

    Mark - 2012-07-19


    I am still having some issues trying to get the CVS GDL version build on my OSX 10.7 (the 0.9.2 release package version from Fink works fine). 

    I am getting the following error when doing the make:

    libtool: Version mismatch error.  This is libtool 2.4 Debian-2.4-2ubuntu1, but the
    libtool: definition of this LT_INIT comes from libtool 2.4.2.
    libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1
    libtool: and run autoconf again.
    make: ***  Error 63
    make: ***  Error 1
    make: ***  Error 1
    make: ***  Error 2

    Any ideas?

    Thanks again,

  • Mark

    Mark - 2012-07-19

    Follow-up on installation of the dev version of GDL on OS_X 10.7.  After removing files and recompiling, I was able to get past the libtool errors reported above (I also switched to using "cmake" instead of ".compile" (as suggested)).

    cmake -DCMAKE_INSTALL_PREFIX=/Applications/GDL_developer/gnudatalanguage/gdl/Compilation/ -DPLPLOTDIR=/sw/lib/plplot -DLIBPROJ4=YES -DLIBPROJ4DIR=/Applications/GDL_developer/gnudatalanguage/gdl/libproj4

    When performing the build with "make" I get the following error:
    Linking CXX executable gdl
    ld: library not found for -lXext
    collect2: ld returned 1 exit status
    make: ***  Error 1
    make: ***  Error 2
    make: ***  Error 2

    Any suggestions on where I might find the Xext library for OS X 10.7?


  • Mark

    Mark - 2012-07-19

    As an addendum to the previous message:

    The CMakeCashe.txt file says:

    //Path to a library.

    which is the correct location of the "libXext.dylib" .

    Any help would be very much appreciated as I am stuck at this point.


  • Alain C.

    Alain C. - 2012-07-23

    Sorry for the delay.

    I used to compiled snapshots of the CVS of GDL on a Snow Leopard (10.6.8).
    I do not have "sudo" rights on this machine, just a remote access. I did compiled CMake, GSL, GraphicMagick and Plplot by myself.

    No problem at all on CMake, GM and the GSL sides.

    I did succeed at the end with plplot 5.9.9, but I need to deactivate large part of drivers:

    $ ../cmake-2.8.6/bin/cmake . -DENABLE_f77=off -DENABLE_f95=off -DPLD_aqt=off -DPLD_wxwidgets=off -DPLD_tcl=off -DENABLE_tcl=off -DCMAKE_INSTALL_PREFIX=/Users/coulais/GDL/plplot-5.9.9/Compilation/
    $ make -j 10
    $ make install

    I used the "configure" way for GDL:
    $ cd gdl-0.9.2cvs120720
    $ mkdir m4
    $ autoreconf -vfi
    $ ./configure  -with-gsl=/Users/coulais/GDL/gsl-1.13/Compilation/ -with-plplot=/Users/coulais/GDL/plplot-5.9.9/Compilation/ -with-GraphicsMagick=/Users/coulais/GDL/GraphicsMagick-1.3.15/Compilation/ -with-netcdf=no -with-hdf=no -with-hdf5=no -with-python=no -with-readlinedir=/opt/local/ -with-pslib=no -with-openmp=no -with-wxWidgets=no -with-Magick=no 

    $ make -j 12

    $ make check
    reports 4 problems:
    ""    -> not a real problem
    ""      -> hum, due to the new keyword Sign, we have no problem on the Unix side :("           -> on this system, Maj and Min in filenames are not distinguished :(
    (HFS+ without case sensitive)
    ""  -> this is related to READ_JPEG, we are exploring that, seems to be related to third party JPEG lib.



Log in to post a comment.