search

conda-forge / pynio-feedstock

A conda-smithy repository for pynio.
BSD 3-Clause "New" or "Revised" License
3 stars 14 forks source link

Older hdf5 and gdal #1

Closed ocefpaf closed 8 years ago

ocefpaf commented 8 years ago

Don't use conda's gcc.

Ping @jakirkham: this is the last one!

conda-forge-admin commented 8 years ago

Hi! This is the friendly conda-forge-admin automated user.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

jakirkham commented 8 years ago

Thanks for the ping. Sorry, I think I missed the other ones. Also, make sure to get rid of libgcc, as well.

ocefpaf commented 8 years ago

Thanks for the ping. Sorry, I think I missed the other ones. Also, make sure to get rid of libgcc, as well.

Those I am not so sure due to the libgomp issue...

jakirkham commented 8 years ago

Ah! Does this need libgomp?

jakirkham commented 8 years ago

We can inspect the binaries to find out. :smile:

ocefpaf commented 8 years ago

We can inspect the binaries to find out. :smile:

I will need to solve a fortran problem first! I thought that was already in the docker image.

jakirkham commented 8 years ago

Ok, so if they need gomp or gfortran we definitely need gcc for OS X. Though Linux should be ok.

jakirkham commented 8 years ago

Yeah, I think we should just leave this one alone. Most users won't have gfortran. So, let's just close this one out.

ocefpaf commented 8 years ago

Ok, so if they need gomp or gfortran we definitely need gcc for OS X. Though Linux should be ok.

So we need to go back to libiconv (pynio dependency) and compile that with conda's gcc for OS X?

jakirkham commented 8 years ago

No, that shouldn't be necessary.

jakirkham commented 8 years ago

libiconv is just C (maybe some C++ too). It doesn't use Fortran or OpenMP.

ocefpaf commented 8 years ago

libiconv is just C (maybe some C++ too). It doesn't use Fortran or OpenMP.

I thought that they should be compiled with the same gcc to play nice together. Just made the change. Let's see how it goes.

jakirkham commented 8 years ago

So, that is a problem I have seen with C++ code particularly when using C++11 features. A good example might be Boost and VIGRA.

jakirkham commented 8 years ago

The problem I saw with libiconv IIRC was that we built with gcc, but didn't include libgcc as a run time requirement. It looked like there were a few other packages like that in the PR (where libiconv was added). That being said, we have tried to avoid using gcc from Continuum and use the system compiler instead. So, I figured we should just remove it in that case.

jakirkham commented 8 years ago

This case seems different as we need gfortran and it isn't provided on either Linux or Mac so we should install Continuum's gcc for both. If we are using OpenMP, we should be able to use the system compiler on Linux, but will need Continuum's gcc on Mac. Otherwise, we should try to use system compilers only. Does this make sense?

ocefpaf commented 8 years ago

Pynio does not seem to like this. I am getting a segfault.

Bye...
/Users/travis/miniconda3/conda-bld/test-tmp_dir/run_test.sh: line 3:  1417 Abort trap: 6           nosetests
TESTS FAILED: pynio-1.5.0beta-np110py27_1
jakirkham commented 8 years ago

Looks like there are some more HDF5 version issues.

jakirkham commented 8 years ago

Have you seen this failure locally?

ocefpaf commented 8 years ago

Have you seen this failure locally?

Yes, but it goes away when I re-build everything with conda's gcc...

jakirkham commented 8 years ago

I was meaning the HDF5 issue that we are seeing here.

ocefpaf commented 8 years ago

I was meaning the HDF5 issue that we are seeing here.

Nope. But I know what that is: gdal is downgrading netcdf :unamused:

(I really should go back to the netCDF recipe!)

ocefpaf commented 8 years ago

I cannot figure out the reason for the hdf5 mismatch. I pinned gdal and the log shows only hdf5 1.8.15 as expected :unamused:

It is late and I will get back to this tomorrow.

......Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.8.16, library is 1.8.15

Edit: it is hdfeos5!

ocefpaf commented 8 years ago

I can confirm it is hdfeos5. I won't pin hdf5 everywhere. I guess it is better just to get netcdf done.

ocefpaf commented 8 years ago

Everything works when I pin against older build that were compiled against the older hdf5. I won't merge this as the new netcdf should fix this for good.

(The failure is the lack of np111 for some packages.)