Third party libraries for Casper

[sgpearse]

This PR modifies our build3rdParty.sh script and circleci configuration to build our libraries on Casper. The libraries are located in /glade/campaign/cisl/vast/vapor/third-party/current. To build on Casper, you must unload ncarenv and set LD_LIBRARY_PATH like so:

module --force unload ncarenv
export LD_LIBRARY_PATH=/glade/campaign/cisl/vast/vapor/third-party/current/lib:$LD_LIBRARY_PATH

[StasJ]

I ran

module --force unload ncarenv

and added

set (THIRD_PARTY_DIR /glade/campaign/cisl/vast/vapor/third-party/current)

to site.NCAR, however I am getting the following error when running cmake:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
HDF5_LIB
    linked by target "common" in directory /glade/u/home/stasj/casper/vapor/lib/common

I confirmed that the dir you specified is being used as other libs are being found by cmake there.

---

On a separate note, since we already have a cmake configuration file for supporting building on NCAR systems, site.NCAR, could support for Casper be added there?

[sgpearse]

I think this is a permissions issue. Please give it another shot.

[StasJ]

I am getting the same error. This is what cmake finds:

THIRD_PARTY_DIR = /glade/campaign/cisl/vast/vapor/third-party/current
Library NETCDF   = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libnetcdf.so
Library UDUNITS2 = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libudunits2.so
Library FREETYPE = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libfreetype.so
Library GEOTIFF  = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libgeotiff.so
Library JPEG     = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libjpeg.so
Library HDF5_LIB = HDF5_LIB-NOTFOUND
Library EXPAT = /glade/campaign/cisl/vast/vapor/third-party/current/lib/libexpat.so

[StasJ]

I am still getting an error:

/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: ../../lib/libcommon.so: undefined reference to `Wasp::GetAppPath(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool)'
collect2: error: ld returned 1 exit status

[sgpearse]

@StasJ - Sam, Nihanth and myself are able to build with the commands below, so this is kind of perplexing.

The fact that 1) we are able to build and 2) ld having trouble with libcommon makes me think the problem lies outside of the 3rd party libraries.

Without being able to replicate this, I can only guess that the build wasn't clean, or ncarenv wasn't removed. make VERBOSE=1 might shed some light.

module --force unload ncarenv
cmake .. -DTHIRD_PARTY_DIR=/glade/campaign/cisl/vast/vapor/third-party/current && make VERBOSE=1 &> build.txt

[StasJ]

@sgpearse Are you also able to run the vapor gui binary you build?

[sgpearse]

@sgpearse Are you also able to run the vapor gui binary you build?

I am. FWIW, I'm unsetting LD_LIBRARY_PATH in ~/.bashrc. When I don't do this I get problems linking to the Qt in /usr/lib64. I'm not sure how that could be related to our own libcommon though but maybe that's worth a shot.

[StasJ]

Could support for casper be added to site.NCAR?

[sgpearse]

I'm guessing that wiping LD_LIBRARY_PATH worked. But I don't like guessing. It would be a big time saver for me if you could provide more details in code reviews where I can't reproduce your findings.

Could support for casper be added to site.NCAR?

My guess to your question is "no" because CMake only compiles. It doesn't run ld at runtime, which can get messed up by environment variables like LD_LIBARAY_PATH.

[StasJ]

I'm guessing that wiping LD_LIBRARY_PATH worked. But I don't like guessing. It would be a big time saver for me if you could provide more details in code reviews where I can't reproduce your findings.

Oh, I already had it working and I was just wondering if it worked for you out of the box, hence my lack of followup. I could've been clearer, though, sorry. It's not ideal but since this is just for dev work, it's fine.

Could support for casper be added to site.NCAR?

My guess to your question is "no" because CMake only compiles. It doesn't run ld at runtime, which can get messed up by environment variables like LD_LIBARAY_PATH.

I was referring to the compiling configuration.

[StasJ]

Launch vapor with the attached session file (./vapor session.vs3) using both the official built version and the version built using these libraries. The official version will show an error message that the linked dataset can't be found. This version will show an empty glitched popup.
session.zip

[sgpearse]

@StasJ I think you're hitting a problem with LD_LIBRARY_PATH again. I know it's a pain. I've tried automating this in site.local but it doesn't persist into the user's environment. The best I can do is add a warning about it. Can you see if the following fixes the problem?

export LD_LIBRARY_PATH=/glade/campaign/cisl/vast/vapor/third-party/current/lib:$LD_LIBRARY_PATH"

Here's the error I see after performing this step:

[StasJ]

With some further testing, module --force unload ncarenv breaks other things like conda support.
export LD_LIBRARY_PATH="/glade/campaign/cisl/vast/vapor/third-party/current/lib:$LD_LIBRARY_PATH" does not fix the issue:

[sgpearse]

@StasJ

With some further testing, module --force unload ncarenv breaks other things like conda support.

Is this an issue? When are we ever forced to use conda in the same environment that we build the GUI?

export LD_LIBRARY_PATH="/glade/campaign/cisl/vast/vapor/third-party/current/lib:$LD_LIBRARY_PATH" does not fix the issue:

I'll take a look if you can provide the path to that session file, but I have a feeling that it's going to work for me like your previous example did. If that happens we will need to ask the rest of the team to verify.

[sgpearse]

@StasJ I noticed that you're running in a conda environment (sys). What happens if you deactivate it?

[StasJ]

Is this an issue? When are we ever forced to use conda in the same environment that we build the GUI?

This may be an issue when debugging the Python API

I'll take a look if you can provide the path to that session file, but I have a feeling that it's going to work for me like your previous example did. If that happens we will need to ask the rest of the team to verify.

It is the same session file I attached earlier.

@StasJ I noticed that you're running in a conda environment (sys). What happens if you deactivate it?

I tried and it had no effect.

[StasJ]

Fully resetting my environment and building from scratch resolved the issue