Created attachment 450984 [details] libmed-3.2.0.ebuild this package is needed for media-gfx/freecad-9999. this ebuild is based on ebuild from here: http://data.gpo.zugaina.org/science/sci-libs/libmed/ the only thing i added is one patch that adds minor fix that prevented to build the package.
Created attachment 450986 [details, diff] libmed-3.2.0-cmake-fortran.patch
Created attachment 450988 [details, diff] libmed-3.2.0-fix-swig-build.patch
Created attachment 450990 [details, diff] libmed-3.2.0-fix-type.patch this patch was added by me and it fixes compilation of the package
(In reply to Miroslav Šulc from comment #0) > Created attachment 450984 [details] > libmed-3.2.0.ebuild > > this package is needed for media-gfx/freecad-9999. > > this ebuild is based on ebuild from here: > http://data.gpo.zugaina.org/science/sci-libs/libmed/ the only thing i added > is one patch that adds minor fix that prevented to build the package. Hi Miroslav, I get a ton of QA warnings and failures: * QA Notice: The following shared libraries lack NEEDED entries * /usr/lib/libmed.so Files matching a file type that is not allowed: usr/lib/libmedC.so usr/lib/libmedimport.so usr/lib/libmed.so usr/lib/python2.7/site-packages/med/_medfilter.so usr/lib/python2.7/site-packages/med/_medmesh.so usr/lib/python2.7/site-packages/med/_medinterp.so usr/lib/python2.7/site-packages/med/_medsubdomain.so usr/lib/python2.7/site-packages/med/_medfamily.so usr/lib/python2.7/site-packages/med/_medparameter.so usr/lib/python2.7/site-packages/med/_medequivalence.so usr/lib/python2.7/site-packages/med/_medprofile.so usr/lib/python2.7/site-packages/med/_medlibrary.so usr/lib/python2.7/site-packages/med/_medfile.so usr/lib/python2.7/site-packages/med/_medlocalization.so usr/lib/python2.7/site-packages/med/_medenumtest.so usr/lib/python2.7/site-packages/med/_medlink.so usr/lib/python2.7/site-packages/med/_medfield.so usr/lib/python2.7/site-packages/med/_medenum.so * ERROR: sci-libs/libmed-3.2.0::gentoo failed: * multilib-strict check failed! Please fix these before we can add the package to the repo. Also 25% of the testsuite fails for me. Please fix the tests too.
Created attachment 496624 [details] new version of the ebuild tests seem to be passing now but python use flag does not work (i was not able to make it work)
Created attachment 496626 [details, diff] libmed-3.2.0-cmake-fortran.patch updated patch version
Created attachment 496628 [details] libmed-3.2.1.ebuild fixing the attachment name in attachments
Miroslav, do you plan to add this to tree at some point? Otherwise freecad-9999 does not make sense to keep any longer in tree (I guess it is also required if built with Qt5). On the other hand if the switch to Qt5 does not enter tree soon it will be kicked anyway.
(In reply to Andreas Sturmlechner from comment #8) > Miroslav, do you plan to add this to tree at some point? Otherwise > freecad-9999 does not make sense to keep any longer in tree (I guess it is > also required if built with Qt5). > > On the other hand if the switch to Qt5 does not enter tree soon it will be > kicked anyway. i have to solve the python issue. i also plan to have a look at freecad-9999 to make it up to date. i hope i'll be able to finish it before it's removed.
Thanks, you shouldn't miss the latest works of Róbert in bug 622726 then towards the qt5 switch.
sci-libs/hdf5 in portage is already at version 1.10.1 (true unstable but anyway) and libmed-3.2.1 doesn't work with this version: checking H5public.h presence... yes checking for H5public.h... yes ///usr/include/H5public.h configure: error: This HDF5 version 1.10.1 must not be used with med-fichier3.2.1. The HDF5 library version used by med-fichier3.y.z MUST NOT be > 1.8 and have to be at least 5-1.8.11. DO NOT TRY TO COMPILE med-fichier3.2.1 version with an HDF5 library which would generate an hdf5 file not compliant with HDF5-1.8.z library. This would BREAK med-fichier compatibility between files with the same revision number ! Sadly no new version upstream for now
One possible workaround is to stay with an older version of hdf5: RDEPEND=" =sci-libs/hdf5-1.8.18[fortran=] sys-cluster/openmpi[fortran=] python? ( ${PYTHON_DEPS} ) " The range needs to be from >=1.8.11 to <1.9.0 1.8.18 is the only hdf5 version in tree in that range.
(In reply to bug2017 from comment #12) Use this instead: RDEPEND=" =sci-libs/hdf5-1.8*[fortran=] sys-cluster/openmpi[fortran=] python? ( ${PYTHON_DEPS} ) "
Oops, nevermind the "bug2017" thing. Accidential paste, it seems(?).
Created attachment 516340 [details] libmed-3.2.1.ebuild changed the ebuild to use cmake, fixed python compilation and other QA issues regarding libdir name. Now there is still a QA pending: * QA Notice: The following shared libraries lack NEEDED entries * /usr/lib64/libmed.so
Created attachment 516342 [details, diff] libmed-3.2.1-disable-python-compile.patch
Created attachment 516344 [details] libmed-3.2.1.ebuild restricted also hdf5 dep
Any news here?
Hey guys, we need this package for FreeCAD ebuild
Created attachment 530768 [details] libmed-3.3.1.ebuild
Created attachment 530770 [details, diff] libmed-3.3.1-cmake-fortran.patch
Created attachment 530772 [details, diff] libmed-3.3.1-disable-python-compile.patch
Added latest libmed 3.3.1 ebuild. There is a problem though - it depends on HDF5 1.8 only. Any ideas what to do?
compiling version 3.3.1 with gcc 6.4.0 and USE=fortran, gives me the following error (version 3.2.1 still compiles fine): [ 89%] Building C object src/ci/CMakeFiles/_ci_static.dir/_MEDequivalenceCorrespondenceSize236.c.o cd /var/tmp/portage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/src/ci && /usr/bin/x86_64-pc-linux-gnu-gcc -DH5_USE_16_API -DMED3_USESTATIC -I/var/tmp/po rtage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/include -I/var/tmp/portage/sci-libs/libmed-3.3.1/work/med-3.3.1_SRC/include -DNDEBUG -march=core2 -O2 -pipe -ggdb -fPIC -o CMakeFiles/_ci_static.dir/_MEDequivalenceCorrespondenceSize236.c.o -c /var/tmp/portage/sci-libs/libmed-3.3.1/work/med-3.3.1_SRC/src /ci/_MEDequivalenceCorrespondenceSize236.c Dependee "/var/tmp/portage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/tools/mdump/CMakeFiles/mdump2.dir/DependInfo.cmake" is newer than depender "/var/t mp/portage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/tools/mdump/CMakeFiles/mdump2.dir/depend.internal". Dependee "/var/tmp/portage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/tools/mdump/CMakeFiles/CMakeDirectoryInformation.cmake" is newer than depender "/v ar/tmp/portage/sci-libs/libmed-3.3.1/work/libmed-3.3.1_build/tools/mdump/CMakeFiles/mdump2.dir/depend.internal". Scanning dependencies of target mdump2 /var/tmp/portage/sci-libs/libmed-3.3.1/work/med-3.3.1_SRC/src/MEDiteratorsF.f:15:56: & MED_OCTA12, MED_PYRA13, MED_PENTA15, MED_PENTA18, MED_HEXA20, 1 Error: Symbol ‘med_penta18’ must be a PARAMETER in DATA statement at (1)
I'm getting issues when compiling libmed 3.2.1 from the fordfrog overlay with swig 3.0.12: medfile_int_wrap.cc: In function 'PyObject* _wrap_MEDINT_insert__SWIG_1(PyObject*, PyObject*)': medfile_int_wrap.cc:14217:73: error: no matching function for call to 'std::vector<int, std::allocator<int> >::insert(SwigValueWrapper<__gnu_cxx::__normal_iterator<int*, std::vector<int, st d::allocator<int> > > >&, std::vector<int, std::allocator<int> >::size_type&, const value_type&)' (arg1)->insert(arg2,arg3,(std::vector< int >::value_type const &)*arg4); adding '--with-swig' to the econf phase regenerates the swig interfaces and let's you have your python interface... that should work with freecad... still working on getting freecad to compile :o src_configure() { econf \ $(use_enable fortran) \ $(use_enable python) \ $(use_enable static-libs static) \ $(use_enable test installtest) \ --with-swig }
(In reply to Guillaume Ranquet from comment #25) > I'm getting issues when compiling libmed 3.2.1 from the fordfrog overlay > with swig 3.0.12: > > medfile_int_wrap.cc: In function 'PyObject* > _wrap_MEDINT_insert__SWIG_1(PyObject*, PyObject*)': > medfile_int_wrap.cc:14217:73: error: no matching function for call to > 'std::vector<int, std::allocator<int> > >::insert(SwigValueWrapper<__gnu_cxx::__normal_iterator<int*, > std::vector<int, st > d::allocator<int> > > >&, std::vector<int, std::allocator<int> > >::size_type&, const value_type&)' > (arg1)->insert(arg2,arg3,(std::vector< int >::value_type const &)*arg4); > > adding '--with-swig' to the econf phase regenerates the swig interfaces and > let's you have your python interface... that should work with freecad... > still working on getting freecad to compile :o > > src_configure() { > econf \ > $(use_enable fortran) \ > $(use_enable python) \ > $(use_enable static-libs static) \ > $(use_enable test installtest) \ > --with-swig > } On my system I am using swig 3.0.12 but I don't have your problem so I don't need --with-swig. Which are the USE flags you are using to compile libmed? Can you indicate the output of "emerge -pv libmed"?
(In reply to Guillaume Ranquet from comment #25) > I'm getting issues when compiling libmed 3.2.1 from the fordfrog overlay > with swig 3.0.12: Please use the ebuilds here attached, they are using cmake and not autoconf
I have finally found time to make further steps to solve the issues, I am attaching here the files for latest 3.3.1 release. Here the list of changes: * added support to mpi * added support to hdf5-1.10 (patch taken from debian) * fixed cmake files to * solve the building issue I was facing (it happened because the building was using the header files of a previous version from the live filesystem) * solve symlinking phase during install * install only shared libs with USE=fortran * fixed tests (I had to disable parallel mode because there is some race condition but I don't have time to look into it) * fixed compatibility of tests with python3 I have also reported the problems upstream (https://www.salome-platform.org/forum/forum_9/658871499) but they don't have a bugreport system so I am not sure the patches will be included in next version :-( I think the ebuild is now in good shape to be considered for insertion in portage. Please test it :-)
Created attachment 541820 [details] libmed-3.3.1.ebuild
Created attachment 541822 [details, diff] libmed-3.3.1-cmake-fortran.patch
Created attachment 541824 [details, diff] libmed-3.3.1-cmakelist.patch
Created attachment 541826 [details, diff] libmed-3.3.1-disable-python-compile.patch
Created attachment 541828 [details, diff] libmed-3.3.1-hdf5-1.10-support.patch taken from Debian
Created attachment 541830 [details, diff] libmed-3.3.1-mpi.patch
Created attachment 541832 [details, diff] libmed-3.3.1-tests.patch
Created attachment 541834 [details, diff] libmed-3.3.1-tests-python3.patch
Created attachment 541952 [details] build.log for proposed ebuild (In reply to Fabio Rossi from comment #28) > ... > Please test it :-) It failed: * ERROR: sci-libs/libmed-3.3.1::local-repo failed (install phase): * No Python implementation set (EPYTHON is null).
(In reply to silver_ghost from comment #37) > Created attachment 541952 [details] > build.log for proposed ebuild > > (In reply to Fabio Rossi from comment #28) > > ... > > Please test it :-) > It failed: > * ERROR: sci-libs/libmed-3.3.1::local-repo failed (install phase): > * No Python implementation set (EPYTHON is null). I have replicated the problem, you are probably using USE=-python, right? I have updated a fixed ebuild, thanks for testing
Created attachment 542064 [details] libmed-3.3.1.ebuild
(In reply to Fabio Rossi from comment #38) > I have replicated the problem, you are probably using USE=-python, right? I > have updated a fixed ebuild, thanks for testing Now it builds.
Created attachment 562970 [details] libmed-3.3.1.ebuild updated the ebuild with the following changes: * EAPI=7 * fixed install location of documentation * fixed python modules to avoid import errors * completed patch for hdf5 1.10 for tests * minor cosmetic changes to the ebuild
Created attachment 562972 [details, diff] libmed-3.3.1-hdf5-1.10-support.patch
Created attachment 562974 [details, diff] libmed-3.3.1-installdoc.patch
Created attachment 562976 [details, diff] libmed-3.3.1-python-imports.patch
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d2fe2fc4df25ac7200748694607ebd53ed142f34 commit d2fe2fc4df25ac7200748694607ebd53ed142f34 Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2019-02-01 12:54:02 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2019-02-01 13:46:12 +0000 sci-libs/libmed-3.3.1: new ebuild Author: Fabio Rossi <rossi.f@inwind.it> Closes: https://bugs.gentoo.org/597768 Package-Manager: Portage-2.3.59, Repoman-2.3.12 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> sci-libs/libmed/Manifest | 2 + sci-libs/libmed/libmed-3.3.1.ebuild | 100 ++++++++++++++++++++++++++++++++++++ sci-libs/libmed/metadata.xml | 8 +++ 3 files changed, 110 insertions(+)
the committed files don't include the patches
(In reply to Fabio Rossi from comment #46) > the committed files don't include the patches one of the patches was too large so i packaged them all together and put them on my web space for download. RC_URI="http://files.salome-platform.org/Salome/other/${MY_P}.tar.gz https://dev.gentoo.org/~fordfrog/distfiles/${P}-gentoo.tar.bz2"
