Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#3936 closed defect (fixed)

Setting up bessie iconv errors FreeBSD

Reported by: robe Owned by: robe
Priority: medium Milestone: PostGIS 2.5.0
Component: QA/buildbots Version: 2.4.x
Keywords: Cc:

Description

I set up 2 new vms. a freebsd (bessie). A deb9 (this one probably won't be a bot, but I made it a slave node on jenkins since I thought it would be easier and help me troubleshoot my issues with bessie).

I do plan to eventually have a 32-bit freebsd (bessie32) and maybe a 32bit deb9 (debbie32).

Anyway both are setup now as slave nodes on debbie's jenkins and while I got deb9 to run cleanly thru trunk clone, build, and check. I'm having some issues with bessie.

 PostGIS is now configured for amd64-unknown-freebsd11.1

 -------------- Compiler Info ------------- 
  C compiler:           cc -g -O2
  SQL preprocessor:     /usr/bin/cpp -traditional-cpp -w -P

 -------------- Dependencies -------------- 
  GEOS config:          /usr/local/bin/geos-config
  GEOS version:         3.6.2
  GDAL config:          /usr/local/bin/gdal-config
  GDAL version:         2.2.2
  PostgreSQL config:    /usr/local/bin/pg_config
  PostgreSQL version:   PostgreSQL 10.1
  PROJ4 version:        49
  Libxml2 config:       /usr/local/bin/xml2-config
  Libxml2 version:      2.9.4
  JSON-C support:       no
  protobuf-c support:   no
  PCRE support:         no
  Perl:                 /usr/local/bin/perl

 --------------- Extensions --------------- 
  PostGIS Raster:       enabled
  PostGIS Topology:     enabled
  SFCGAL support:       disabled
  Address Standardizer support:       disabled

 -------- Documentation Generation -------- 
  xsltproc:             /usr/local/bin/xsltproc
  xsl style sheets:     
  dblatex:              
  convert:              /usr/local/bin/convert
  mathml2.dtd:          http://www.w3.org/Math/DTD/mathml2/mathml2.dtd

First to get past configure, I had to do this:

sh autogen.sh
./configure --with-projdir=/usr/local

otherwise it couldn't find the proj_api.h

But now I'm getting this. At first I didn't have iconv installed, so thought that may have been issue, but after install,

pkg install iconv

still have this:

libtool: link: cc -I ../liblwgeom -g -O2 -fPIC -DPIC -Wall -Wmissing-prototypes -I/usr/local/include shpopen.o dbfopen.o getopt.o shpcommon.o safileio.o shp2pgsql-core.o shp2pgsql-cli.o -o .libs/shp2pgsql -fstack-protector -Wl,--as-needed -Wl,-R/usr/local/lib  ../liblwgeom/.libs/liblwgeom.so -L/usr/local/lib -lgeos_c -lproj -lm -lpthread -Wl,-rpath -Wl,/usr/local/lib
shp2pgsql-core.o: In function `utf8':
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:69: undefined reference to `libiconv_open'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:83: undefined reference to `libiconv'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:110: undefined reference to `libiconv_close'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:88: undefined reference to `libiconvctl'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:89: undefined reference to `libiconv'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:92: undefined reference to `libiconvctl'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:93: undefined reference to `libiconv'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:101: undefined reference to `libiconv_close'
/usr/home/jenkins/workspace/Test_Slave/trunk/loader/shp2pgsql-core.c:97: undefined reference to `libiconv_close'
cc: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:103: shp2pgsql] Error 1
gmake[2]: Leaving directory '/usr/home/jenkins/workspace/Test_Slave/trunk/loader'
gmake[1]: *** [GNUmakefile:16: all] Error 1
gmake[1]: Leaving directory '/usr/home/jenkins/workspace/Test_Slave/trunk'
*** Error code 2

Change History (12)

comment:1 by robe, 6 years ago

strk helped me work thru this as noted in:

https://lists.osgeo.org/pipermail/postgis-devel/2017-November/026738.html

I think the main issue is my ICONV variable is messed up in the generated Makefile

ICONV_LDFLAGS=-lc

So I changed it to

ICONV_LDFLAGS= -liconv

and that fixed the issue. Now to figure out where that stupid setting is happening.

comment:2 by strk, 6 years ago

It's in configure.ac, from line 350

comment:3 by robe, 6 years ago

As noted on mailing list Bessie has 2 iconvs.

One located in /usr/bin/iconv

/usr/bin/iconv --version

outputs

iconv: unrecognized option `--version'
Usage:  iconv [-cs] -f <from_code> -t <to_code> [file ...]
        iconv -f <from_code> [-cs] [-t <to_code>] [file ...]
        iconv -t <to_code> [-cs] [-f <from_code>] [file ...]
        iconv -l

and another

/usr/local/bin/iconv --version

outputs

iconv (GNU libiconv 1.14)
Copyright (C) 2000-2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible.

The /usr/local/bin/iconv seems to respond to usual command —version.

The other does not.

Seems the default when I call

iconv is the /usr/bin/iconv

comment:4 by robe, 6 years ago

As far as .so /.a I have a .so and .a I got these

/usr/local/bin/iconv
/usr/local/include/iconv.h
/usr/local/lib/libiconv.a
/usr/local/lib/libiconv.so
/usr/local/lib/libiconv.so.2
/usr/local/lib/libiconv.so.2.5.1

and in usr/lib folder these things

libkiconv.a     libkiconv.so    libkiconv_p.a

comment:5 by robe, 6 years ago

Milestone: Management 2.0PostGIS 2.5.0

I setup a bessie32 same config except this time I didn't do

pkg iconv

I have the same issue with her, and doing the hack of below after ./configure

rm loader/Makefile.bak
sed -i .bak 's/ICONV_LDFLAGS= -lc/ICONV_LDFLAGS=-liconv/' "loader/Makefile"

works on her as well.

For completeness from mailing list http://lists.osgeo.org/pipermail/postgis-users/2017-November/042494.html

strk noted this

The code setting ICONV_LDFLAGS, in configure.ac, is as follows:

  dnl libconv defines iconv_open to libiconv_open, so we'll check that directly
  AC_CHECK_LIB([iconv], [libiconv_open], [ICONV_LDFLAGS="$ICONV_LDFLAGS -liconv" HAVE_ICONV=1], [])
  if test "x$HAVE_ICONV" = "x"; then
    dnl Check for iconv included as part of libc, using iconv_open
    AC_CHECK_LIB([c], [iconv_open], [ICONV_LDFLAGS="$ICONV_LDFLAGS -lc" HAVE_ICONV=1], [])
    if test "x$HAVE_ICONV" = "x"; then
      dnl But it's possible this implementation of libiconv doesn't have a libiconv_* define
      AC_CHECK_LIB([iconv], [iconv_open], [ICONV_LDFLAGS="$ICONV_LDFLAGS -liconv" HAVE_ICONV=1], [])
      if test "x$HAVE_ICONV" = "x"; then
        dnl No iconv library was found; issue a warning to the console
        AC_MSG_ERROR([Could not find libiconv. Please install libiconv and libiconv-devel.])
      fi
    fi
  fi

In order to get just '-lc' you should have found NO `libiconv_open` in libiconv,
while you would have found `iconv_open` in libc.

But your error message complains about:

  undefined reference to `libiconv_open'

which you report as being found when you set ICONV_LDFLAGS to -liconv
...

So unclear to me why first test fails yet libiconv does have libiconv_open evidentally.

Doing this:

pkg info | grep libiconv

I get:

libiconv-1.14_11               Character set conversion library

Seems to be a common freebsd issue though of all solutions just overriding CFLAGS or libs

https://github.com/pdewacht/brlaser/issues/10

https://forums.freebsd.org/threads/50274/

All seem like workarounds and not solving the fundamental configure failure

comment:6 by robe, 6 years ago

I thought I had tried this before but perhaps I was mistaken. Just tried again on bessie 32 and seemed to work.

sh autogen.sh
./configure --with-projdir=/usr/local --with-libiconv=/usr/local

Still unclear to me why I have to explicitly specify these paths.

I'll try on bessie as well to confirm.

comment:7 by strk, 6 years ago

Maybe we should look for a different symbol instead of iconv_open/libiconv_open

comment:8 by strk, 6 years ago

Maybe /usr/local/lib is NOT in your default search path ?

comment:9 by robe, 6 years ago

dumb then that when I do

pkg add ..

it installs everything there. That probably explains why cunit is not being picked up but why are both geos and GDAL picked up though.

Perhaps int's the include dir. I noticed both GDAL and GEOS have the gdal-config, geos-config in /usr/local/bin

I think both Cunit and I suspect libconv need the include folder.

comment:10 by robe, 6 years ago

hmm meant pkg install

pkg info libiconv 

is pretty informative.

libiconv-1.14_11
Name           : libiconv
Version        : 1.14_11
Installed on   : Sun Nov 26 09:52:52 2017 UTC
Origin         : converters/libiconv
Architecture   : FreeBSD:11:amd64
Prefix         : /usr/local
Categories     : devel converters
Licenses       : GPLv3
Maintainer     : gnome@FreeBSD.org
WWW            : http://www.gnu.org/software/libiconv/
Comment        : Character set conversion library
Options        :
        DOCS           : on
        ENCODINGS      : on
        PATCHES        : off
Shared Libs provided:
        libiconv.so.2
        libcharset.so.1
Annotations    :
        repo_type      : binary
        repository     : FreeBSD
Flat size      : 2.21MiB

aha you are right, the /usr/local/bin is in PATH but not include or lib folders though why does -liconv manage to find the libiconv though if I don't explicitly add to ./configure or is it just dumb luck because proj is installed in /usr/local/lib so doing —with-proj makes the compile work

echo $PATH

outputs:

/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/robe/bin

I think I got to start experimenting with Jails next and run all jobs in a jail.

comment:11 by robe, 6 years ago

Resolution: fixed
Status: newclosed

I'm going to close this for now as I have a working solution. Either add to with or probably fiddle with other flags.

comment:12 by strk, 6 years ago

Dumb luck, IMHO. We should tweak ./configure to make sure CFLAGS and LDFLAGS is cleaned up before testing for presence, and make sure to add the include directory in which things are found.

Still, if something is in /usr/include and something else in /usr/local/include we'd end up with both in the compile line and in case of multiple installs the first one will be used.

In other words: it can be a real mess!

Note: See TracTickets for help on using tickets.