Open sgpearse opened 1 month ago
I think this is a permissions issue. Please give it another shot.
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
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
@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
@sgpearse Are you also able to run the vapor gui binary you build?
@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.
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.
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.
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 like so:
module --force unload ncarenv