#95 Create shared library

[Ole Streicher]

This patch put all common stuff into a shared library and just links the "gdl" executable (created from gdl.cpp) to it. The main advantage is that one can create both the executable and the Python extension in one step, and that the footprint of a common installation is smaller by a factor 2.
The library is called libgnudatalanguage.so to avoid confusion with the libgdl from the GNOME project.
This patch also includes the changes that are needed to create executable and Python extension in one step (specifically the definition of lib::command_line_args is moved from gdl.cpp to basic_fun.cpp).

[Ole Streicher]

Oops, small type. Use the following patch instead.

[GregJung]

I've added the patches attached below,
I tried this build using PYTHON_MODULE=OFF and it doesn't work yet,
in opensuse 13.2 (gcc 4.8.3), using cmake V3.3.2.
Also cmake 3.02, I've combined your patches to make the attached
combined.patch, which I applied to the minimal patches here:
https://sourceforge.net/p/gnudatalanguage/patches/102/

greg@linux-gc09:/f/gdlso> grep -n target_link_lib src/CMakeLists.txt
281:    target_link_libraries(pythongdl gnudatalanguage)
284:target_link_libraries(gdl gnudatalanguage)
286:    target_link_libraries(gdl -fopenmp)
289:    target_link_libraries(gdl readline)
293:target_link_libraries(gnudatalanguage antlr) 
295:target_link_libraries(gnudatalanguage ws2_32)
297:target_link_libraries(gnudatalanguage PRIVATE ${LIBRARIES})

cmake in both cases wont generate because it has a problem with
the way target_link_libraries is used:

CMake Error at src/CMakeLists.txt:297 (target_link_libraries):
  The plain signature for target_link_libraries has already been
  used with the target "gnudatalanguage".  All uses of target_link_libraries with a target must be either all-keyword or all-plain.

  The uses of the plain signature are here:

   * src/CMakeLists.txt:293 (target_link_libraries)

line 297 is changed to
target_link_libraries(gnudatalanguage ${LIBRARIES})

it will generate ok this way - but it breaks my usage of a static plplot library.
tested, with results identical to earlier run:

greg@linux-gc09:/d/bld/gdl/gdlso/suse> make check >& check.out
*** Error in `-quiet': munmap_chunk(): invalid pointer: 0x00007f3d78001a90 ***
*** Error in `../src/gdl': munmap_chunk(): invalid pointer: 0x00007fbaa4001a90 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x7283f)[0x7fbac1def83f]
/lib64/libc.so.6(+0x780ae)[0x7fbac1df50ae]
/usr/lib64/libstdc++.so.6(_ZNSs7reserveEm+0x66)[0x7fbac2b27066]
greg@linux-gc09:/d/bld/gdl/gdlso/suse> tail -15 check.out

The following tests FAILED:
         40 - test_bug_3285659.pro (Failed)
         87 - test_file_move.pro (Failed)
Errors while running CTest
Makefile:127: recipe for target 'test' failed

So , linux build works. I'd go one more step and make it an option.

[Ole Streicher]

The reason is that antlr has also to be built as shared library. For this, do the IF(PYTHON_MODULE) part on CMAKE in this directory unconditionally, as shown in the additional patch.

[Ole Streicher]

One more addition: for some reason, readline was disabled when the python module is compiled. The next patch re-enables it :-)

[GregJung]

I'd like to see the standalone option preserved, when python is not to be included.
I do a lot of plplot experiments and lately have gone to static plplotlib for builds that
I want to use later; that works when libplplot-xx.a is added to make gdl, but can be
more difficult when a shared image is attempted.

[Ole Streicher]

Check out the patches I have put on github: they provide an additional option SHARED_LIB=YES|NO.
However, I think that plplot is not special; with the same argument one could ask to make anything linking to gsl static since he wants to play with libgsl. Or libc,
Why don't you put your experimental plplot libs into a non-standard install dir and use LD_LIBRARY_PATH to use it?

Best regards

Ole

[GregJung]

on opensuse there's not a big call for LD_LIBRARY_PATH
But yes, for "special" libraries I usually hold them seperately and use, e.g.,
-DPLPLOTDIR=, then if it is a shared library
I have to maintain copies of the .dll or the .so ;
DGAPHICKSMAGICKDIR=<> and -DWXWIDGETSDIR=<> are also used.

So, I've tested the github patches for the standalone case and for
non-python SHARED_LIB=ON cases and there are a few errors:
gdl_antlr is named as the antlr library, and the link for standalone
wasn't fully accomodated. Also for mingw, a gnurx library after shlwapi is needed.
The attached patch creates gdl_antlr shared library
(and not tested yet, uses it) in SHARED_LIB case and does the
old libantlr.a otherwse. Based on 211b14b, it passes a smoke test in
mingw32 and looks good to build the shared libs.

[Ole Streicher]

Sorry, I forgot to mention that the shared lib patch is the last one in a series of patches, which also target the antlr problem. They are tested on Ubuntu 14.04, but should run on openSUSE as well.

BTW, if you have a "smoke test" for Windows, coiuld sou try to set this up on a public test platform, like Appveyor? This would help to create a Continious Integration solution for GDL.

[Sylwester Arabas]

Closing here, let's move the discussion to gihub: https://github.com/gnudatalanguage/gdl/issues/49