trying to build but failing on ubuntu

[adamcandy]

From @francispoulin on April 15, 2017 13:28

Thanks for putting this together. I am very keen to try it out but I am still at the first phase of trying to installing it.

I believe I have installed the required libraries. One difference is I installed python-gdal on ubuntu and I have to import it using "import gdal" instead of "import GDAL" and I believe you have in the code. Not sure if that is a problem or not.

I downloaded your code and tried to build it but didn't get very far. Do you have any advice as to what I should do?

$ python setup.py build
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'library_dirs'
  warnings.warn(msg)
running build
running build_py
running egg_info
writing shingle.egg-info/PKG-INFO
writing top-level names to shingle.egg-info/top_level.txt
writing dependency_links to shingle.egg-info/dependency_links.txt
writing entry points to shingle.egg-info/entry_points.txt
reading manifest file 'shingle.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching 'MANIFEST'
warning: no files found matching '*.py' under directory 'shingle/'
warning: no files found matching '*.so' under directory 'shingle/'
warning: no files found matching '*.h' under directory 'spud/include/'
no previously-included directories found matching 'dataset'
warning: no previously-included files matching '*' found under directory 'dataset/'
writing manifest file 'shingle.egg-info/SOURCES.txt'
running build_ext
building 'libspud' extension
gcc -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fno-strict-aliasing -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-lMBuS3/python2.7-2.7.12=. -fstack-protector-strong -Wformat -Werror=format-security -fPIC -I/home/fpoulin/software/Shingle/spud/include -I/home/fpoulin/software/Shingle/spud/include -I/usr/include/python2.7 -c spud/python/libspud.c -o build/temp.linux-x86_64-2.7/spud/python/libspud.o
In file included from spud/python/libspud.c:3:0:
/home/fpoulin/software/Shingle/spud/include/spud.h:38:3: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
   void spud_clear_options();
   ^~~~
/home/fpoulin/software/Shingle/spud/include/spud.h:39:3: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
   void* spud_get_manager();
   ^~~~
/home/fpoulin/software/Shingle/spud/include/spud.h:70:3: warning: function declaration isn’t a prototype [-Wstrict-prototypes]
   void spud_print_options();
   ^~~~
x86_64-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-Bsymbolic-functions -Wl,-z,relro -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-lMBuS3/python2.7-2.7.12=. -fstack-protector-strong -Wformat -Werror=format-security -Wl,-Bsymbolic-functions -Wl,-z,relro -Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/python2.7-lMBuS3/python2.7-2.7.12=. -fstack-protector-strong -Wformat -Werror=format-security build/temp.linux-x86_64-2.7/spud/python/libspud.o -L/home/fpoulin/software/Shingle/spud -lspud -o build/lib.linux-x86_64-2.7/libspud.so -flat_namespace -lstdc++
x86_64-linux-gnu-gcc: error: unrecognized command line option ‘-flat_namespace’; did you mean ‘-Wnamespaces’?
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

Copied from original issue: adamcandy/Shingle#3

[adamcandy]

Thank you @francispoulin for your interest in the Shingle library. The dependencies of the library in version 2 have grown to include libspud to formally manage the diverse range of option types -- and the building of this library appears to be failing here.

Libspud dependency build suggestions

To help solve this problem for you and others and generally make the setuptools build more agnostic to the underlying system the build process has been significantly simplified. All dependencies provided with the source are now build as extensions within setup.py (extensions with C++ code existed before, but this now eliminates the -lspud linking, where -flat_namespace / -Wnamespaces were used). The configure -- make build route still exists, but this Python route should make it easier.

On an updated source (to release v2.0.2), you should be able to simply call:

make

to build the library. This runs python setup.py build_ext, as will be called with your python setup.py build above. It also uses --inplace to build libspud.so directly in the root source folder. You can also use your python setup.py build instead if you prefer to build these C++ extensions and collect the library together in a separate build folder -- and subsequently install system-wide, if needed.

To run through the unit tests and suite of verification test cases, assessed to expected metrics, follow this with

make unittest

and

make test

I recommend the above, but alternatively here are some other suggestions:

• The Spud library code is hosted at: https://launchpad.net/spud, so you could install the library from this code, or its linked Ubuntu packages.
• Use the configure and Makefile mechanisms in the Shingle source code to build the libspud.so dynamic library that is the required (or further, enter the spud folder and build separately first)
• Use the pre-prepared PyPI packages, e.g.:

pip install shingle

Note there is also a PyPI package for the Diamond GUI (spud-diamond), used to examine BRML descriptions. The PyPI dxdiff package (dxdiff) is needed with this.

General dependency support

To make sure the library builds successfully on a wide range of underlying systems, the above is tested on Travis (follow the link in this badge: ). This is tested on Ubuntu LTS versions Precise 12.04, Trusty 14.04 and Xenial 16.04, both through Docker container builds and in Travis distributions.

If you find any other issues with dependencies not being found, please refer to these configuration files for lists of apt (and pip) packages -- or use the Docker files themselves directly, which eliminates any potential local configuration issues. The configuration files are in the root source tree:

• .travis.yml -- configuration for 7 different builds over the 3 Ubuntu LTS systems
• Dockerfile -- Build and testing in Ubuntu Trusty 14.04
• Dockerfile_precise -- Build and testing in Ubuntu Precise 12.04
• Dockerfile_xenial -- Build and testing in Ubuntu Xenial 16.04

Note the first has configurations for environments build up using apt packages and also instead using pip. So following this, you could install dependencies using pip install through setuptools/distutils instead of Ubuntu apt packages. I would recommend using apt packages first if possible.

GDAL dependency

Using the Ubuntu python-gdal on this release branch to bring in GDAL is fine and should not raise any problems.

All 7 Travis builds are now green ), which mean the Shingle library builds, unit tests pass and the longer verification tests are successful, following the suring up of the Python setuptools build process. I will update the manual to reflect the above, and please let me know if this helps fix the issue you have had, or if you experience any other issues. I would be very interested to hear how you are using the library and welcome input / am happy to help further.

[francispoulin]

Thank you so much for going through the effort of updating this library for me, and the community, to use more easily.

I decided to take the easiest route and simply do,

$ ./configure $ make $ make unittest $ make test

It is still doing the last part and it looks like it's going to take some time but I wanted to let you know that there is a small problem with the unit test. Sorry if I misunderstood but what I found was the following,

$ make unittest /bin/sh: 1: py.test: not found

I believe that the make test worked. I see a lot of PASS and don't see any obvious errors.

I also succeeded in building the docs.

When I looked at 2.1 Quick Start, I started following the instructions and see that a data folder has been inserted, which isn't there in the docs. Easy to figure out but wanted to let you know. I moved into the data folder and tried the following

gmsh -2 Antarctica_all_valid.geo Antarctica_all_valid.msh

I am happy to see that I tried to plot the Amundsen_Sea example and that seemed to work. Now I need to figure out how to use this.

In terms of my interest, I am curious to learn if I can use this software to specify idealized geometries for oceanic basins. In particular I have been developing software to solve idealized oceanic models such as Quasi-Geostrophy and Shallow Water (working on others as well) using Firedrake. You can see a demo that computes the wind-driven gyre in a square at the following:

http://firedrakeproject.org/demos/qg_winddrivengyre.py.html

What I am hoping to do is to do this for say the Northern Atlantic or Pacific to see what affect the coastlines have on the wind-driven gyres and the basin modes.

Do you think that your software might help with this? Even it if can't, it looks very interesting and is something I would like to learn more about.