Bug 194060
| Summary: | graphics/qgis python support broken since gcc 4.8 was imported | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Matthieu Volat <mazhe> | ||||||||||||||||
| Component: | Individual Port(s) | Assignee: | Thomas Zander <riggs> | ||||||||||||||||
| Status: | Closed FIXED | ||||||||||||||||||
| Severity: | Affects Only Me | CC: | lbartoletti, rhurlin, riggs, thierry | ||||||||||||||||
| Priority: | --- | Flags: | rhurlin:
maintainer-feedback+
|
||||||||||||||||
| Version: | Latest | ||||||||||||||||||
| Hardware: | Any | ||||||||||||||||||
| OS: | Any | ||||||||||||||||||
| See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192605 | ||||||||||||||||||
| Attachments: |
|
||||||||||||||||||
|
Description
Matthieu Volat
2014-10-01 07:16:34 UTC
Asking maintainer for feedback. Also involving thierry@, since we had a similar issue with py-numpy in ports r369447, bug 188114. When `USES= fortran' is defined, LDFLAGS is set to:
LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin
and usually this error is caused by this missing flags.
Check that LDFLAGS is propagated to the Makefiles and not overwritten, and that should fix it.
(Sorry, I cannot check it at the moment)
Created attachment 147980 [details]
Patch adding fortran and LDFLAGS + modernizing
Could you please check the attached patch? It seems to work for me.
There is still some warnings:
- Warning: loading of qt translation failed [/usr/local/share/qt4/translations/qt_fr_FR]
- Couldn't load plugin 'processing' from ...
- ImportError: No module named psycopg2
Could be solved by adding a RUN_DEPENDS on databases/py-psycopg2
but these are just warnings...
Yes! I was trying to enforce LD_LIBRARY_PATH in the python interpreter initialization at first, but it was not working. This works very well, it indeed gives the psycopg2, but at least, this is a "clean" missing dep error :) Thank you very much Sorry for the late response of me (maintainer). I am on a business trip until tomorrow evening and so have to wait until then for a deeper look. Some days ago (2014-09-09) I filed a patch [1] which should solve much of the problems we have with gcc4[78], python dependencies, brokeness on FreeBSD < 9.0 and a dated GRASS dependency. It is not committed until now. Could you please try the patch in Bug 192605 against the original port (without your FORTRAN and LDFLAGS approach) and report back, if it solves your described problems? [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192605 No problem, No, if I apply only Bug 192605 patch on vanilla port directory, the loading still fails with a "cannot load scimath" from the processing plugin (but linker messages about libgfortran/libgcc messages disappeared from stderr) Ok, thanks for testing. So I will try to merge the two patches in a way, that the LDFLAGS and python problems disappear and my other fixes also work. Because I am very busy at the moment, that could take a few days (including testing). Created attachment 148115 [details] merge of patches from Bugs 192605 and 194060 (previous one) Enhancements are: - Enable Fortran again (thanks to thierry@) - Add python and pgsql to USES= - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624) - Ensure presence of GRASS, if option enabled - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem) - Correct typo for 'RUN_DEPENDS' in previous patch, sorry. - Remove dirrmtry entries ------------------------------------------------------- #portlint -AC WARN: /usr/ports/graphics/qgis/pkg-plist: [495]: enumerating info files in the plist is deprecated in favor of adding info files into the Makefile using the INFO macro. 0 fatal errors and 1 warnings found. This warning is wrong, because it relates to qgis.g.info, a QGIS pendant for the GRASS command 'g.info'. It is not an info file. ------------------------------------------------------- Tested with RedPorts. RedPorts is not fully functional at the moment: [1] https://redports.org/buildarchive/20141008192546-34197/ No problems on my side, still working like a charm. Created attachment 148189 [details] Additionally use mapserver Enhancements are now: - Enable Fortran again (thanks to thierry@) - Add python and pgsql to USES= - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624) - Ensure presence of GRASS, if option enabled - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem) - Correct typo for 'RUN_DEPENDS' in previous patch, sorry. - Remove dirrmtry entries - graphics/mapserver (+ www/fcgi) for mapscript capabilities - rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%% The usage of 'real' mapserver port is important to get QGIS extensions like 'RT MapServer Explorer' working. They depend on mapscript functionality from MapServer port. For this, python bindings option in graphics/mapserver must be enabled. (In reply to Rainer Hurling from comment #10) > Created attachment 148189 [details] > Additionally use mapserver > > Enhancements are now: > - Enable Fortran again (thanks to thierry@) > - Add python and pgsql to USES= > - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624) > - Ensure presence of GRASS, if option enabled > - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme > - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem) > - Correct typo for 'RUN_DEPENDS' in previous patch, sorry. > - Remove dirrmtry entries > - graphics/mapserver (+ www/fcgi) for mapscript capabilities > - rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%% > > The usage of 'real' mapserver port is important to get QGIS extensions like > 'RT MapServer Explorer' working. They depend on mapscript functionality from > MapServer port. For this, python bindings option in graphics/mapserver must > be enabled. I tried it, I see a side problem that was here since the begining: regarding python support, a lot of options are put in the "BUILD_DEPENDS" variable, which is wrong: qgis will need them at runtime (there will be problems if autoremove is run, or probably if gqis is installed via pkg repos). Not sure which part of them should be also put in RUN_DEPENDS, but I'm guessing everything except devel/py-sip. Aside from that, I don't see any problem. Created attachment 148499 [details]
repeat most BUILD_DEPENDS also in RUN_DEPENDS
Thanks for your testing. I think, you are right. So I include most python deps also in RUN_DEPENDS.
Created attachment 148520 [details] updated patch against r371283 Yet another patch, after r371293 from bapt@, who removed all @dirrm entries in pkg-plist. Apart from that, no functional change against the previous, now obsolete patch [1]. [1] https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148499 Created attachment 148661 [details] updated USES= After r371326 from mva@, which integrates python into USES=, another QGIS patch is necessary. No functional changes against bug 148520 I would have liked to have seen a poudriere log, but I am taking pity on poor Rainer who had had to regenerate the patch a few times and moving this to patch-ready now. and now QGis 2.6 is out. Do you wait to update the version and apply the new patch ? Thanks (In reply to coder from comment #16) > and now QGis 2.6 is out. Do you wait to update the version and apply the new > patch ? > > Thanks I don't think qgis 2.6 will fix that kind of problems (since it is relatively FreeBSD/ports centric), and since the patch only affect the port Makefile, it should not either affect it. I'm 100% happy since I can live with a patched port tree, but this issue was resolved a while ago and maybe it would be nice to push it to everybody? On the other hand, delaying it until qgis 2.6 is commited seems a bit more fuzzy, since we don't know how fast the port will be updated? But great news btw, I guess I'll try to bump my local version and see what happens :) (In reply to Matthieu Volat from comment #17) > I don't think qgis 2.6 will fix that kind of problems (since it is > relatively FreeBSD/ports centric), and since the patch only affect the port > Makefile, it should not either affect it. I'm 100% happy since I can live > with a patched port tree, but this issue was resolved a while ago and maybe > it would be nice to push it to everybody? You are right. Most of the changes, which are in my last submitted patch (148661), is not relevant upstream. > On the other hand, delaying it until qgis 2.6 is commited seems a bit more > fuzzy, since we don't know how fast the port will be updated? I am working on an update towards 2.6.0 yet. But it could take some days, since I don't want to introduce new problems ;) > But great news btw, I guess I'll try to bump my local version and see what > happens :) I would suggest, that in the meantime, someone with a commit bit should bring this patch (148661) into the tree. Then I will prepare the update from 2.4.0 to 2.6.0 in a new bugzilla report. A commit references this bug: Author: riggs Date: Sat Nov 8 07:53:09 UTC 2014 New revision: 372306 URL: https://svnweb.freebsd.org/changeset/ports/372306 Log: Fix runtime errors with gcc 4.8 Additional enhancements: - Enable Fortran again (thanks to thierry@) - Add python and pgsql to USES= - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624) - Ensure presence of GRASS, if option enabled - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem) - Correct typo for 'RUN_DEPENDS' in previous patch, sorry. - Remove dirrmtry entries - graphics/mapserver (+ www/fcgi) for mapscript capabilities - rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%% PR: 194060 Submitted by: mazhe@alkumuna.eu Reviewed by: rhurlin@gwdg.de (maintainer) Changes: head/graphics/qgis/Makefile head/graphics/qgis/pkg-plist Building the various OPTIONS permutations took a while, but now committed, thanks! Thanks a lot! It feels nice to have FreeBSD strong even in specialized field of study :) |
