Summary: | sci-libs/mathgl-1.8-r1 depends on deprecated use flag | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
Component: | New packages | Assignee: | Andrey Grozin <grozin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sci |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
mathgl-1.8.1-numpy.patch
mathgl-1.8.1-openmp.patch |
Description
Helmut Jarausch
2009-03-27 08:19:36 UTC
@Andrey: BTW please fix your email address in metadata.xml. (Also sci-visualization/udav) (In reply to comment #1) > @Andrey: BTW please fix your email address in metadata.xml. > (Also sci-visualization/udav) > What's wrong with it? Helmut. I'm now working on mathgl-1.8.1 ebuild (and udav-0.5.1). I hoped to complete this work on Sunday, but, unfortunately, there are some problems. Hope to solve them in a few days. The new version will not depend on swig[python] or swig[octave]. And I'll correct my email address :-) Just wait a few days. Created attachment 187603 [details]
mathgl-1.8.1-numpy.patch
Hi,
I tried to build by hand mathgl, and I needed this patch. I was able to build with fltk:1.1. It builds examples by default though.
Hope this helps for the bump.
I did it by if use python; then local numpy_h numpy_h=$(python_get_sitedir)/numpy/core/include/numpy/arrayobject.h einfo "fixing numpy.i" sed -e "s|<numpy/arrayobject.h>|\"${numpy_h}\"|" \ -i lang/numpy.i \ || die "sed failed" fi I also had to apply the attached patch, because gcc-4.1.2 does not understand -fopenmp and I don't have -lgomp. But I got stuch: compiling mgl_fltk.cpp gives syntax errors in /usr/include/libintl.h which is a standard header from glibc. I cannot understand this. I have fltk-1.1.9. Created attachment 187626 [details, diff]
mathgl-1.8.1-openmp.patch
The patch
Applying this patch is probably good only with a openmp use flag since it will prevent gcc > 4.2 users for using openmp and gcc-4.3.2* is already stable on a few architectures. It seems this one would require more work unless depending on more recent toolchain. Fixed in 1.8.1 (and 1.8-r1 removed). |