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 Flags
Error report in qgis error window
none
Patch adding fortran and LDFLAGS + modernizing
thierry: maintainer-approval+
merge of patches from Bugs 192605 and 194060 (previous one)
none
Additionally use mapserver
rhurlin: maintainer-approval+
repeat most BUILD_DEPENDS also in RUN_DEPENDS
rhurlin: maintainer-approval+
updated patch against r371283
rhurlin: maintainer-approval+
updated USES= rhurlin: maintainer-approval+

Description Matthieu Volat 2014-10-01 07:16:34 UTC
Created attachment 147872 [details]
Error report in qgis error window

Hello,

There is a problem with qgis port right now, regarding to python support: since port gcc version was bumped to 4.8, there is multiple errors when starting qgis, from the interface (see attachment), and on stderr:

ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found
ERROR 1: /lib/libgcc_s.so.1: version GCC_4.6.0 required by /usr/local/lib/gcc48/libgfortran.so.3 not found

The program starts, but functionality is reduced... From the look of it, it seems to be somehow related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=188114, except that this bug was fixed (and numpy direct usage in python interpreter works).

Trying stuff like :

% env LD_LIBRARY_PATH=/usr/local/lib/gcc48 qgis 

results in a nasty crash, and building it entirely with gcc48 is a no-go since it does C++... I guess something is kinda wrong in the embeeded python/plugin framework, but I have little idea to fix that right now...
Comment 1 Marcus von Appen freebsd_committer freebsd_triage 2014-10-03 07:04:14 UTC
Asking maintainer for feedback. Also involving thierry@, since we had a similar issue with py-numpy in ports r369447, bug 188114.
Comment 2 Thierry Thomas freebsd_committer freebsd_triage 2014-10-03 07:19:29 UTC
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)
Comment 3 Thierry Thomas freebsd_committer freebsd_triage 2014-10-04 19:20:28 UTC
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...
Comment 4 Matthieu Volat 2014-10-06 07:13:15 UTC
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
Comment 5 Rainer Hurling freebsd_committer freebsd_triage 2014-10-06 08:51:09 UTC
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
Comment 6 Matthieu Volat 2014-10-07 08:34:07 UTC
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)
Comment 7 Rainer Hurling freebsd_committer freebsd_triage 2014-10-07 08:51:32 UTC
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).
Comment 8 Rainer Hurling freebsd_committer freebsd_triage 2014-10-08 20:37:15 UTC
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/
Comment 9 Matthieu Volat 2014-10-09 07:44:03 UTC
No problems on my side, still working like a charm.
Comment 10 Rainer Hurling freebsd_committer freebsd_triage 2014-10-11 14:03:40 UTC
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.
Comment 11 Matthieu Volat 2014-10-20 11:46:44 UTC
(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.
Comment 12 Rainer Hurling freebsd_committer freebsd_triage 2014-10-20 13:08:20 UTC
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.
Comment 13 Rainer Hurling freebsd_committer freebsd_triage 2014-10-20 19:55:21 UTC
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
Comment 14 Rainer Hurling freebsd_committer freebsd_triage 2014-10-26 11:46:34 UTC
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
Comment 15 John Marino freebsd_committer freebsd_triage 2014-10-31 17:49:10 UTC
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.
Comment 16 Loïc Bartoletti freebsd_committer freebsd_triage 2014-11-02 19:48:10 UTC
and now QGis 2.6 is out. Do you wait to update the version and apply the new patch ?

Thanks
Comment 17 Matthieu Volat 2014-11-03 07:52:34 UTC
(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 :)
Comment 18 Rainer Hurling freebsd_committer freebsd_triage 2014-11-03 08:02:28 UTC
(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.
Comment 19 commit-hook freebsd_committer freebsd_triage 2014-11-08 07:53:21 UTC
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
Comment 20 Thomas Zander freebsd_committer freebsd_triage 2014-11-08 07:56:19 UTC
Building the various OPTIONS permutations took a while, but now committed, thanks!
Comment 21 Matthieu Volat 2014-11-08 08:14:36 UTC
Thanks a lot! It feels nice to have FreeBSD strong even in specialized field of study :)