Hello all,
Is the 'current' beta release version compiling on freebsd?
I got the code from the release and I tried with freebsd 10.1 and got
some error regarding libiconv, mostly on the new 'temporal' tools.
If there's anything I can do to help 
thanks for the work, highly appreciated.
F
-=--=-=-
Fábio Augusto Salve Dias
http://sites.google.com/site/fabiodias/
Hi Fábio,
On Mon, Dec 29, 2014 at 10:41 PM, Fábio Dias <fabio.dias@gmail.com> wrote:
Hello all,
Is the 'current' beta release version compiling on freebsd?
ideally yes.
I got the code from the release and I tried with freebsd 10.1 and got
some error regarding libiconv, mostly on the new 'temporal' tools.If there's anything I can do to help
Great! First of all, please post your error message, e.g. here:
http://pastebin.com/
thanks for the work, highly appreciated.
Your feedback is welcome, too.
Please consider to switch your b4 download to releasebranch, then
testing of updates is easier:
cd some/path/grass7beta4/
svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0
# now simply
svn update
to get latest release related updates (there were many in the past few days).
Eventually it would be great to update the FreeBSD section here:
http://grasswiki.osgeo.org/wiki/Compile_and_Install#FreeBSD_.2F_NetBSD
Best
Markus
Hi,
So, I started with a fresh checkout (from the URL you told me to switch to).
The full log is on http://pastebin.com/2n9vswif
The "important" part, afaik, is :
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_close'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_open'
So I've tried with --with-iconv on the configure, not that this option
exist... Then I manually changed a Makefile, on one of the directories
with error. Added -liconv to he LIBES var, then the make worked. My
guess would be that configure isn't passing along the -liconv properly
in this context...
Thanks again,
F
-=--=-=-
Fábio Augusto Salve Dias
http://sites.google.com/site/fabiodias/
On Mon, Dec 29, 2014 at 7:50 PM, Markus Neteler <neteler@osgeo.org> wrote:
Hi Fábio,
On Mon, Dec 29, 2014 at 10:41 PM, Fábio Dias <fabio.dias@gmail.com> wrote:
Hello all,
Is the 'current' beta release version compiling on freebsd?
ideally yes.
I got the code from the release and I tried with freebsd 10.1 and got
some error regarding libiconv, mostly on the new 'temporal' tools.If there's anything I can do to help
Great! First of all, please post your error message, e.g. here:
http://pastebin.com/thanks for the work, highly appreciated.
Your feedback is welcome, too.
Please consider to switch your b4 download to releasebranch, then
testing of updates is easier:cd some/path/grass7beta4/
svn switch https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0# now simply
svn updateto get latest release related updates (there were many in the past few days).
Eventually it would be great to update the FreeBSD section here:
http://grasswiki.osgeo.org/wiki/Compile_and_Install#FreeBSD_.2F_NetBSDBest
Markus
On Tue, Dec 30, 2014 at 1:31 AM, Fábio Dias <fabio.dias@gmail.com> wrote:
Hi,
So, I started with a fresh checkout (from the URL you told me to switch to).
ok, fine.
The full log is on http://pastebin.com/2n9vswif
The "important" part, afaik, is :
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_close'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_open'So I've tried with --with-iconv on the configure, not that this option
exist... Then I manually changed a Makefile, on one of the directories
with error. Added -liconv to he LIBES var, then the make worked.
Ok. You could enable that globally here:
include/Make/Platform.make
which is autogenerated. Please take a look at
config.log
and search therein for libiconv. It will contain the error why it wasn't found.
Markus
Sorry for the delay, I got stuck recompiling all packages that used png
I looked at the output from configure (which I'll post fully tomorrow,
if needed), and no error was found regarding liconv. I was checking
the UPDATING file from ports, apparently, some functionality from
libiconv was moved to the standard libc. However, libiconv was later
reintroduced because some of the features were still missing from
libc. My guesstimate of the problem would be that, when testing for
libiconv functionality, without -liconv, configure gets the answer
from libc and doesn't include -liconv. When we try to compile, we use
stuff that isn't yet on libc and things go awry.
Changing the platform.make removed that error, but with the new
configure/configure.in (just changed in the svn), it doesn't work
anymore. I changed the makefile directly, on v.generalize (which is
the part that interests me the most), and it compiled successfully.
-=--=-=-
Fábio Augusto Salve Dias
http://sites.google.com/site/fabiodias/
On Tue, Dec 30, 2014 at 11:42 AM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Dec 30, 2014 at 1:31 AM, Fábio Dias <fabio.dias@gmail.com> wrote:
Hi,
So, I started with a fresh checkout (from the URL you told me to switch to).
ok, fine.
The full log is on http://pastebin.com/2n9vswif
The "important" part, afaik, is :
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_close'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_open'So I've tried with --with-iconv on the configure, not that this option
exist... Then I manually changed a Makefile, on one of the directories
with error. Added -liconv to he LIBES var, then the make worked.Ok. You could enable that globally here:
include/Make/Platform.make
which is autogenerated. Please take a look at
config.logand search therein for libiconv. It will contain the error why it wasn't found.
Markus
On Wed, Dec 31, 2014 at 5:29 AM, Fábio Dias <fabio.dias@gmail.com> wrote:
Sorry for the delay, I got stuck recompiling all packages that used png
No problem.
I looked at the output from configure (which I'll post fully tomorrow,
if needed), and no error was found regarding liconv.
But what did it report? On Linux, I get
checking for libintl.h... yes
checking for iconv.h... yes <<---
checking for langinfo.h... yes
You, too? If you get "no" there, please check the file "config.log".
I was checking
the UPDATING file from ports, apparently, some functionality from
libiconv was moved to the standard libc. However, libiconv was later
reintroduced because some of the features were still missing from
libc. My guesstimate of the problem would be that, when testing for
libiconv functionality, without -liconv, configure gets the answer
from libc and doesn't include -liconv. When we try to compile, we use
stuff that isn't yet on libc and things go awry.
Mhh, so we need to test for a specific function via configure. I see
for example in configure.in this test:
LOC_CHECK_LIBS(z,deflate,zlib,$ZLIBLIBPATH,ZLIB,)
Perhaps something similar we need to write for libiconv? Which
function does it specifically complain about?
BTW: I will try to get a VM running, currently downloading:
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/11.0-CURRENT/amd64/20141222/
Changing the platform.make removed that error, but with the new
configure/configure.in (just changed in the svn), it doesn't work
anymore.
Please post the error. The recent change should be completely
unrelated to your issue.
I changed the makefile directly, on v.generalize (which is
the part that interests me the most), and it compiled successfully.
Maybe you posted it but which libiconv function was missing before so
that we can add a test?
Markus
Fábio Dias wrote:
The "important" part, afaik, is :
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_close'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_open'So I've tried with --with-iconv on the configure, not that this option
exist... Then I manually changed a Makefile, on one of the directories
with error. Added -liconv to he LIBES var, then the make worked. My
guess would be that configure isn't passing along the -liconv properly
in this context...
This looks like a mismatch between iconv implementations, i.e. using
the headers from libiconv with a libc which supports iconv natively.
In the configure script, the header checks and the library checks are
disconnected.
One part of the script checks that iconv.h exists (more precisely,
that a source file which contains nothing but "#include <iconv.h>" can
be pre-processed without error).
Another part checks that a function named iconv or libiconv exists,
either when linking with the default libraries (i.e. with no -l
switches) or with -liconv or -lgiconv. To be precise, it checks that a
test program which references the function can be linked without
error. The test program doesn't include any headers; it declares its
own prototype for the function (that's just how autoconf's
AC_CHECK_FUNC and AC_CHECK_LIB macros work).
If you use a "libiconv"-style implementation, the headers define iconv
as a macro which expands to libiconv (likewise for iconv_open and
iconv_close). The library provides functions called libiconv etc.
If the platform's libc provides iconv, the functions are named iconv,
iconv_open, iconv_close (i.e. no "lib" prefix).
What I suspect is happening is that the linkage checks:
AC_CHECK_FUNC(iconv, ICONVLIB=, [
AC_CHECK_LIB(iconv, iconv, ICONVLIB=-liconv, [
AC_CHECK_LIB(giconv, iconv, ICONVLIB=-lgiconv, [
AC_CHECK_FUNC(libiconv, ICONVLIB=, [
AC_CHECK_LIB(iconv, libiconv, ICONVLIB=-liconv, [
AC_CHECK_LIB(giconv, libiconv, ICONVLIB=-lgiconv, [
AC_MSG_WARN([*** Unable to locate iconv() function.])
ICONVLIB=
])])])])])])
AC_SUBST(ICONVLIB)
determine that the iconv function is available by default, with no
additional libraries required (i.e. it's built into libc). I.e. the
first test succeeds, resulting in ICONVLIB being empty.
But the iconv.h header which is found during compilation is for a
libiconv implementation, not for libc's implementation (possibly due
to the use of /usr/local/include). So the resulting program has a
dependency upon the functions from libiconv (which isn't linked)
rather than those in libc (which is linked).
If my suspicion is correct, you should be able to avoid the issue by
creating an additional include directory containing only libc's
iconv.h file (or a symlink to it) and placing that directory before
/usr/local/include in the argument to the --with-includes= switch.
Alternatively, you could temporarily remove or rename the iconv.h in
/usr/local/include while compiling GRASS (I'm not sure why that would
need to be there if the system libc provides iconv).
--
Glynn Clements <glynn@gclements.plus.com>
# locate iconv.h
/usr/include/iconv.h
/usr/include/sys/iconv.h
/usr/local/include/boost/math/special_functions/detail/iconv.hpp
/usr/local/include/iconv.h
/usr/local/include/libgsf-1/gsf/gsf-output-iconv.h
/usr/local/lib/gcc48/include/c++/gnu/gcj/convert/Input_iconv.h
/usr/local/lib/gcc48/include/c++/gnu/gcj/convert/Output_iconv.h
/usr/ports/lang/gcc/work/gcc-4.8.3/libjava/gnu/gcj/convert/Input_iconv.h
/usr/ports/lang/gcc/work/gcc-4.8.3/libjava/gnu/gcj/convert/Output_iconv.h
The files /usr/include/iconv.h and /usr/local/include/iconv.h are different.
I removed the local one, re-run ./configure (both iconv related
messages: yes) and gmake. Same deal. No -liconv included on
include/Make/Platform.make, same error when linking.
I also removed the --with-includedir=local and added iconv.h from another dir:
/configure --with-includes=~/ --with-postgres --with-pthread
--with-gdal --with-includes=/usr/local/include
--with-libs=/usr/local/lib
--with-freetype-includes=/usr/local/include/freetype2 --with-readline
--with-geos --with-wxwidgets --with-lapack --with-sqlite
Same deal. It says yes for both iconv tests and doesn't link it.
It is important to say that I didn't fiddle around much, I think. The
box is pretty much a fresh free 10.1 install...
-=--=-=-
Fábio Augusto Salve Dias
http://sites.google.com/site/fabiodias/
On Wed, Dec 31, 2014 at 8:01 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Fábio Dias wrote:
The "important" part, afaik, is :
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_close'
/usr/home/diasf/releasebranch_7_0/dist.x86_64-unknown-freebsd10.1/lib/libgrass_gis.7.0.0svn.so:
undefined reference to `libiconv_open'So I've tried with --with-iconv on the configure, not that this option
exist... Then I manually changed a Makefile, on one of the directories
with error. Added -liconv to he LIBES var, then the make worked. My
guess would be that configure isn't passing along the -liconv properly
in this context...This looks like a mismatch between iconv implementations, i.e. using
the headers from libiconv with a libc which supports iconv natively.In the configure script, the header checks and the library checks are
disconnected.One part of the script checks that iconv.h exists (more precisely,
that a source file which contains nothing but "#include <iconv.h>" can
be pre-processed without error).Another part checks that a function named iconv or libiconv exists,
either when linking with the default libraries (i.e. with no -l
switches) or with -liconv or -lgiconv. To be precise, it checks that a
test program which references the function can be linked without
error. The test program doesn't include any headers; it declares its
own prototype for the function (that's just how autoconf's
AC_CHECK_FUNC and AC_CHECK_LIB macros work).If you use a "libiconv"-style implementation, the headers define iconv
as a macro which expands to libiconv (likewise for iconv_open and
iconv_close). The library provides functions called libiconv etc.If the platform's libc provides iconv, the functions are named iconv,
iconv_open, iconv_close (i.e. no "lib" prefix).What I suspect is happening is that the linkage checks:
AC_CHECK_FUNC(iconv, ICONVLIB=, [
AC_CHECK_LIB(iconv, iconv, ICONVLIB=-liconv, [
AC_CHECK_LIB(giconv, iconv, ICONVLIB=-lgiconv, [
AC_CHECK_FUNC(libiconv, ICONVLIB=, [
AC_CHECK_LIB(iconv, libiconv, ICONVLIB=-liconv, [
AC_CHECK_LIB(giconv, libiconv, ICONVLIB=-lgiconv, [
AC_MSG_WARN([*** Unable to locate iconv() function.])
ICONVLIB=
])])])])])])
AC_SUBST(ICONVLIB)determine that the iconv function is available by default, with no
additional libraries required (i.e. it's built into libc). I.e. the
first test succeeds, resulting in ICONVLIB being empty.But the iconv.h header which is found during compilation is for a
libiconv implementation, not for libc's implementation (possibly due
to the use of /usr/local/include). So the resulting program has a
dependency upon the functions from libiconv (which isn't linked)
rather than those in libc (which is linked).If my suspicion is correct, you should be able to avoid the issue by
creating an additional include directory containing only libc's
iconv.h file (or a symlink to it) and placing that directory before
/usr/local/include in the argument to the --with-includes= switch.Alternatively, you could temporarily remove or rename the iconv.h in
/usr/local/include while compiling GRASS (I'm not sure why that would
need to be there if the system libc provides iconv).--
Glynn Clements <glynn@gclements.plus.com>
Fábio Dias wrote:
The files /usr/include/iconv.h and /usr/local/include/iconv.h are different.
Does /usr/include/iconv.h contain the macros?
#define iconv_open libiconv_open
#define iconv libiconv
#define iconv_close libiconv_close
If not, it looks like it's now picking up some other iconv.h.
According to this:
https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html
FreeBSD 10-CURRENT and later has iconv in libc, so no additional
libraries should be linked. But that will require the use of the
system iconv.h rather than a libiconv iconv.h.
I removed the local one, re-run ./configure (both iconv related
messages: yes) and gmake. Same deal. No -liconv included on
include/Make/Platform.make, same error when linking.I also removed the --with-includedir=local and added iconv.h from another dir:
/configure --with-includes=~/ --with-postgres --with-pthread
--with-gdal --with-includes=/usr/local/include
--with-libs=/usr/local/lib
--with-freetype-includes=/usr/local/include/freetype2 --with-readline
--with-geos --with-wxwidgets --with-lapack --with-sqliteSame deal. It says yes for both iconv tests and doesn't link it.
Can you show the actual compilation commands being used, specifically
for parser_interface.c in lib/gis (that's where the lib/gis -> iconv
dependency comes from; lib/driver and lib/cairodriver also have iconv
dependencies)?
--
Glynn Clements <glynn@gclements.plus.com>
Full installation log, fresh system:
http://pastebin.com/ARDd1HQv
/usr/include/iconv.h
http://pastebin.com/yf6ycz66
/usr/local/include/iconv.h (installed by cairo afaik)
http://pastebin.com/7BMNAMYA
gmake on lib/gis
http://pastebin.com/PAgAfnfh
As far as I understood, not all things iconv are implemented in the
system version.
-=--=-=-
Fábio Augusto Salve Dias
http://sites.google.com/site/fabiodias/
On Wed, Jan 7, 2015 at 2:35 PM, Glynn Clements <glynn@gclements.plus.com> wrote:
Fábio Dias wrote:
The files /usr/include/iconv.h and /usr/local/include/iconv.h are different.
Does /usr/include/iconv.h contain the macros?
#define iconv_open libiconv_open
#define iconv libiconv
#define iconv_close libiconv_closeIf not, it looks like it's now picking up some other iconv.h.
According to this:
https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html
FreeBSD 10-CURRENT and later has iconv in libc, so no additional
libraries should be linked. But that will require the use of the
system iconv.h rather than a libiconv iconv.h.I removed the local one, re-run ./configure (both iconv related
messages: yes) and gmake. Same deal. No -liconv included on
include/Make/Platform.make, same error when linking.I also removed the --with-includedir=local and added iconv.h from another dir:
/configure --with-includes=~/ --with-postgres --with-pthread
--with-gdal --with-includes=/usr/local/include
--with-libs=/usr/local/lib
--with-freetype-includes=/usr/local/include/freetype2 --with-readline
--with-geos --with-wxwidgets --with-lapack --with-sqliteSame deal. It says yes for both iconv tests and doesn't link it.
Can you show the actual compilation commands being used, specifically
for parser_interface.c in lib/gis (that's where the lib/gis -> iconv
dependency comes from; lib/driver and lib/cairodriver also have iconv
dependencies)?--
Glynn Clements <glynn@gclements.plus.com>
Fábio Dias wrote:
Full installation log, fresh system:
http://pastebin.com/ARDd1HQv/usr/include/iconv.h
http://pastebin.com/yf6ycz66/usr/local/include/iconv.h (installed by cairo afaik)
http://pastebin.com/7BMNAMYAgmake on lib/gis
http://pastebin.com/PAgAfnfh
IOW, libgis is fine, but libgrass_cairodriver (which presumably pulls
in /usr/local/include/iconv.h) has a libiconv dependency.
I don't see any easy solution other than to remove or hide
/usr/local/include/iconv.h while building GRASS.
--
Glynn Clements <glynn@gclements.plus.com>
(@64055)
Additional stuff
# portmaster databases/py-sqlite3 textproc/xmlcatmgr
x11-toolkits/wxgtk28 x11-toolkits/py-wxPython28 (default options all
around - takes a while and pulls in a lot of stuff)
then I removed the /usr/local/include/iconv.h
$ ./configure ...
$ gmake
Errors in:
/usr/home/diasf/grass70_release/gui/wxpython/iclass
ImportError: Numeric,numarray or NumPy not found.
Which is weird, because math/py-numpy is already installed.....
F
--
-=--=-=-
Fábio Augusto Salve Dias
ICMC - USP
http://sites.google.com/site/fabiodias/
On Sat, Jan 10, 2015 at 6:51 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:
Fábio Dias wrote:
Full installation log, fresh system:
http://pastebin.com/ARDd1HQv/usr/include/iconv.h
http://pastebin.com/yf6ycz66/usr/local/include/iconv.h (installed by cairo afaik)
http://pastebin.com/7BMNAMYAgmake on lib/gis
http://pastebin.com/PAgAfnfhIOW, libgis is fine, but libgrass_cairodriver (which presumably pulls
in /usr/local/include/iconv.h) has a libiconv dependency.I don't see any easy solution other than to remove or hide
/usr/local/include/iconv.h while building GRASS.--
Glynn Clements <glynn@gclements.plus.com>
Fábio Dias wrote:
Errors in:
/usr/home/diasf/grass70_release/gui/wxpython/iclassImportError: Numeric,numarray or NumPy not found.
Which is weird, because math/py-numpy is already installed.....
This is a known issue with the wx.lib.plot module:
http://lists.osgeo.org/pipermail/grass-dev/2014-November/071713.html
--
Glynn Clements <glynn@gclements.plus.com>