Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
There is a new stable version of Grass (version 5.4.0) which is not in the portage tree. Reproducible: Always Steps to Reproduce: 1. 2. 3.
From web site: GRASS GIS (Geographic Resources Analysis Support System) is an open source, Free Software Geographical Information System (GIS) with raster, topological vector, image processing, and graphics production functionality that operates on various platforms through a graphical user interface and shell in X-Window. submissions welcome http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
I have added grass-5.7.0.ebuild. It works for me but please note that it is a copy of grass-5.0.3.ebuild and is intended to be corrected and made perfect by somebody who knows how to do ebuilds. I just needed to have working grass 5.7.0 and used the approach "to make it work". The ebuild requires gdal package which is not in the portage tree but you can find gdal-1.2.5.ebuild here in the bug system. Now grass installs into /usr/grass-5.7.0 but I think it would be better to install it into /usr/grass5 because some other applications (like qgis) may optionally link to it. I hope that this ebuild helps those who need grass 5.7.0 urgently (as I do) and that someone will make this ebuild to comply to all rules etc. I'm sorry but I don't have time to study ebuild manual :-( BTW: marazm will hopefully have better ebuild than this for you next week :-)
Created an attachment (id=44781) [details] grass-5.7.0.ebuild
Created an attachment (id=45384) [details] Grass-5.7.0 ebuild This is 5.7 ebuild. 5.7 is unstable grass branch, but it compiles with this ebuild well. Can anybody on amd64 compile grass with enabled 64bit support? Any suggestions, coments etc. welcome.
Created an attachment (id=47857) [details] Ebuild for GRASS 5.7.0 patched for freetype2 I am attaching fixed ebuild for GRASS 5.7.0 The dependency on proj library now reflects correct position in Portage tree. We need to patch one file in the sources, together with configure script, to allow GRASS compile with freetype2.
Created an attachment (id=47858) [details] Freetype2 patch for grass 5.7.0
Created an attachment (id=48580) [details] add libX11 when linking to libgif Several files referenced libgif without linking to libX11, so I made this patch to add -lX11 to each link. I guess this is not the "real" fix and is probably a bad idea if you are building without X. Example: gcc -rdynamic -L/var/tmp/portage/grass-5.7.0/work/grass-5.7.0/dist.i686-pc-linux -gnu/lib -o /var/tmp/portage/grass-5.7.0/work/grass-5.7.0/dist.i686-pc-linux- gnu/etc/bin/cmd/d.path OBJ.i686-pc-linux-gnu/main.o OBJ.i686-pc-linux-gnu/select .o -lgrass_display -lgrass_raster -lgrass_vect -lgrass_dig2 -lgrass_dgl -lgrass_ rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase -L/usr/lib -lgdal -lgra ss_dgl -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz-lm -lz /usr/lib/libgif.so.4: undefined reference to `XDestroyImage' /usr/lib/libgif.so.4: undefined reference to `XGetWindowAttributes' /usr/lib/libgif.so.4: undefined reference to `XGetImage' /usr/lib/libgif.so.4: undefined reference to `XGetPixel' /usr/lib/libgif.so.4: undefined reference to `XQueryColors' collect2: ld returned 1 exit status make[2]: *** [/var/tmp/portage/grass-5.7.0/work/grass-5.7.0/dist.i686-pc-linux-g nu/etc/bin/cmd/d.path] Error 1 make[2]: Leaving directory `/var/tmp/portage/grass-5.7.0/work/grass-5.7.0/displa y/d.path'
Created an attachment (id=48930) [details] Ebuild for GRASS 5.4.0 (current stable GRASS version) this is an ebuild for GRASS 5.4.0 (the current stable GRASS version) based on the grass-5.0.3-ebuild. It works for me (on x86). This ebuild installs GRASS without GDAL support since GDAL is not yet in the portage tree. If you have GDAL, you can change the definition of 'myconf' in the ebuild. Like for the other GRASS-ebuilds, gcc should be built with f77.
Created an attachment (id=49458) [details] Grass 6.0.0 Beta1 ebuild Grass 6.0.0 Beta 1 ebuild for testing. As I understand, 6.x will replace 5.7 branch and become new unsatble/testing branch. Good news are that this ebuild doesnt need freetype2 patch, as 5.7, and, yes, it will run your Qgis too. Please report any bugs etc. Oh, yeah. IMHO we shuld change X and Gdal from USE flags to requirements, as Grass 5.7 was failing w/o them and 6.0 is former 5.7 :) Another thing: can somebody mark this bug to depend from bug #39942 ?
Created an attachment (id=49463) [details] Patch to fix small bug in 6.0.0beta1 ebuild
Created an attachment (id=49464) [details] Grass 5.4.0 ebuild This 5.4.0 ebuild is better: 1) BLAS and LAPACK are optional; 2) Gdal ebuild exists as bug #39942; 3) No use for NLS flag = removed. Comments etc.?
Grass 5.7 fails to build without Gdal. 6.0 - not tested, but IMHO will fail too.
I have gdal-1.2.5 installed, but the build fails in configure with: checking whether to use GDAL... yes checking for gdal-config... /usr/bin/gdal-config checking for GDALOpen... no checking for GDALOpen... no configure: error: *** Unable to locate GDAL library.
If you are talking about grass-6.0.0beta1, imho this is a bug in configure.in. I I had the same problem, then I changed these lines in configure.in (starting on line 626) and it worked (you have to run autoconf): ac_save_libs="$LIBS" LIBS="$GDAL_LIBS $LIBS" # begin changed code #AC_CHECK_FUNC(GDALOpen,[],[ #LIBS="$GDAL_DEP_LIBS $LIBS" #AC_CHECK_FUNC(GDALOpen,[GDAL_LIBS="$GDAL_LIBS $GDAL_DEP_LIBS"],[ # AC_MSG_ERROR([*** Unable to locate GDAL library.]) #]) #]) LIBS="$GDAL_DEP_LIBS $LIBS" AC_CHECK_FUNC(GDALOpen,[GDAL_LIBS="$GDAL_LIBS $GDAL_DEP_LIBS"],[ AC_MSG_ERROR([*** Unable to locate GDAL library.]) ]) #AC_CHECK_FUNC(xdrmem_create, XDRLIB=, [ #AC_CHECK_LIB(sun, xdrmem_create, XDRLIB=-lsun, [ #AC_CHECK_LIB(nsl, xdrmem_create, XDRLIB=-lnsl, [ #AC_CHECK_LIB(rpclib, xdrmem_create, XDRLIB=-lrpclib, [ # AC_MSG_ERROR([*** Unable to locate XDR functions.]) #])])])]) # end changed code Suggestion: what about splitting this bug into requests for every single grass version? E.g. grass 5.4.0 works well without GDAL, so bug 39942 doesn't really block here.
James Umbanhowar: Thats intresting. I compiled Grass60b1 on 3 Gentoos w/o problems. Have You installed gdal from #39942 ebuild? Have You file /usr/bin/gdal-config? Thomas Schorr: Gdal, Grass and Qgis need a maintainer. Grass 5.4 is now stable branch and I duno how many bugfix relases there will be, but starting new bug for Grass 6.0.x IMHO is a good idea. It looks like You understand those things - so You can take my Grass 6.0.x ebuild, enchance it and start new bug, if You want to maintain Grass ebuilds :) Im too limited on computing resources to test Grass with different USE flags and - more important - Im 0 in C/C++ and other programming to solve problems.
MZM: Yes, I used the ebuild from 39942. A similar thing happened with the 5.7.0 ebuild. Thomas: Thanks for the help, but after applying your fix I had to run autoconf twice, the first time I got the following errors: configure.in:346: warning: AC_CANONICAL_HOST invoked multiple times autoconf/specific.m4:363: AC_CYGWIN is expanded from... configure.in:346: the top level configure.in:41: error: possibly undefined macro: AC_MSG_ERROR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. Then I ran autoconf again and didn't get the error, just the warnings. Am I correct in seeing that your correction is to simply delete "AC_CHECK_FUNC(GDALOpen,[],[" and its closing brackets "])"? Now when I run configure I get this error: checking for IceConnectionNumber in -lICE... yes checking for curses.h... yes checking curses.h WINDOW structure component... _maxy checking for initscr in -lncurses... yes checking for keypad in -lncurses... yes ./configure: line 9723: syntax error near unexpected token `fi' ./configure: line 9723: `fi'
I have attached a small patch that should solve bug 80218 for the grass-5.4.0.ebuild. James: You probably need another autoconf version - you need autoconf-2.13 for this configure.in. But anyway, I have experimented a bit and in fact it seems to come down to missing references to libX11 (see comment #7). So my fix probably was just a hack that covered the real problem, sorry:-(. You should be able to check this if you use the original configure file and then look at the last 50-70 lines of the file config.log - it should show something similar to what is mentioned in comment 7. What I don't know now is wether a) this is a bug in GDAL/GDAL-ebuild (because adding -L/usr/lib/X11R6 -lX11 to gdal-config seems to fix it) b) it is a bug in configure.in because libX11 is not referenced for testing GDAL Open - once I had commented out the tests for GDALOpen in configure.in, GRASS was built without problems. c) the patch from comment 7 is appropriate. What do the others think? MZM: as you can see from above, my knowledge is in no way better than yours, and I have 0 experience with maintaining. But if you are still interested I'd like to give it a try - I'd really like to see more grass ebuilds in the portage tree:-) But before I sign for the job (and open a new bug for grass6.0.0), are there any guidelines for maintainers? Can you point me to some documentation?
Created an attachment (id=50152) [details] patch for grass5.4.0.ebuild
Im not the right person to who ask dev. related qs. Im newbee - usin Gentoo not more than ~3 months. Better ask on #gentoo http://www.gentoo.org/doc/en/ebuild-submit.xml Have You tested Yours patch? I had lots of problems with blas and lapack. Finaly I found Grass to compile cleanly with blas-atlas and lapack not lapack-atlas or some other blas/lapack versions. Abbout X there is Q: is any point to build Grass without X, if it requires X? What will happen if I build Grass with patch from comment #7 and then unmerge X? Its wery possible, that GDAL has other gotchas too - its configure script offers some posibilities, that break its building ;)
yes, I have tested the patch - I had to use ACCEPT_KEYWORDS="~x86" interactive=1 emerge lapack-atlas/lapack-blas first, then grass compiled without problems. I also have compiled with the not-atlas version of both lapack and blas and it worked. What kind of problems did you have? About X: I never compiled grass without X because I need X. But on the other hand, if gdal-config references -lgif, then probably it should also reference -lX11, since it is libgif that depends on -lX11.
My problem was definitely the X11 problem, but the patch in 7 did not help. I have little knowledge of config files, but all I did was to add an -lX11 to the part of configure file where it looks for GDAL and it works now. Is this a bug in GDAL?
Created an attachment (id=50725) [details] Grass 6.0.0 beta2 ebuild Grab and test new Grass 6.0.0 beta2! I corrected bug from comment 21. If user wants GDAL, then he needs X too.
Created an attachment (id=51930) [details] Patch for grass-6.0.0beta2 At last I found some time to test the 6.0.0beta2 patch. Here are some comments: First I tried to install grass-6.0.0beta2 without gdal (USE="-gdal"). configure resulted in an error "Unable to open GDAL library". Are there any experiences installing grass6 without GDAL? According to http://grass.itc.it/grass60/source/REQUIREMENTS.html, GDAL is optional - as opposed to X, which is mentioned as a requirement. Then I tried USE="gdal X" which reemerged gdal-1.2.5, but resulted in the same error (the one that was described here several times before). config.log says (somewhere in the last 50 lines): ... configure:7179: checking for GDALOpen configure:7205: gcc -o conftest -O2 -mcpu=i686 -fomit-frame-pointer -Wl,--export-dynamic conftest.c -ljpeg -lgeotiff -ltiff -lpng -lnetcdf -lz -lm -ldl -L/usr/lib -lpq -L/usr/lib -lgdal 1>&5 /usr/lib/libgif.so.4: undefined reference to `XDestroyImage' /usr/lib/libgif.so.4: undefined reference to `XGetWindowAttributes' /usr/lib/libgif.so.4: undefined reference to `XGetImage' /usr/lib/libgif.so.4: undefined reference to `XGetPixel' /usr/lib/libgif.so.4: undefined reference to `XQueryColors' collect2: ld returned 1 exit status configure: failed program was: #line 7182 "configure" ... adding "-lX11 -L/usr/X11R6/lib" to CONFIG_DEP_LIBS in gdal-config fixed this, and grass-6.0.0beta2 compiled without further problems. I guess James' fix from #21 would perhaps lead to the same result. I changed lapack/blas to virtual to keep my lapack/blas settings from #18. One last comment: IMHO grass6 should go into a new slot, because otherwise it will unmerge an existing grass5 installation (this happend to me...). I have attached a small patch with my changes to the grass-6.0.0beta2-ebuild: X and GDAL are requirements, virtual blas/lapack, SLOT="6". Still you will perhaps have to check/change gdal-config.
Created an attachment (id=55558) [details] Grass-6.0.0 ebuild Hi all, please grab and test this Grass ebuild. I hope it will work w/o problems. Important changes - added --with-cxx flag cuz ./configure does not detect g++ and g++ is requerd for r.terraflow module. Some aditional cleanups too :)
Yes, this one worked for me without any modifications (USE="postgres blas fftw lapack").
Thanks for the ebuild, it works for me on amd64!
(In reply to comment #24) I have Grass-6.0.0 compiled on my AMD64 desktop but I cannot execute Grass using the command 'grass'.
That's correct. To start GRASS use command grassXY, where XY are version numbers. In case with 6.0.x, it will be grass60. You can have more than one GRASS installed on Your Gentoo box. I.E. grass54, grass57, grass60, grass61 and You can work with GRASS version that is best for Your needs. If lauching GRASS with correct command fails, please, add more info. (In reply to comment #27) > (In reply to comment #24) > > I have Grass-6.0.0 compiled on my AMD64 desktop but I cannot execute Grass using > the command 'grass'.
A modified 5.4.0 ebuild is now in portage; 5.0.3 broke on Freetype and the gd library being obsoleted (plus it's really old anyway). Both gdal and ogdi are updated and in testing, and both Grass 5.4.0 and 6.0.0 should work with the current USE flags and arches (please test on additional arches if you can). I'll work on an updated 5.7.0 when I get a chance; as always, file any bugs if you find any...
(In reply to comment #29) > I'll work on an updated 5.7.0 when I get a chance; as always, file any bugs if > you find any... There is no need for 5.7.x as there exists 6.0.x. 5.7.x was just 6.x development branch. 5.4 is still used for some old extensions. Look in roadmap: http://grass.itc.it/devel/roadmap.php There is upcoming 6.0.1 - a 6.0.0 bugfix release.
