Opened 4 years ago

Closed 4 years ago

#2213 closed defect (fixed) undefined symbol: json_tokener_errors

Reported by: mloskot Owned by: pramsey
Priority: medium Milestone: PostGIS 2.1.0
Component: postgis Version: trunk
Keywords: json-c Cc:


Ubuntu 12.04 (32-bit) with json-c build and installed from its current json-c Git master (I couldn't find .deb packages):

$ grep '\#define JSON_C_VERSION ' /usr/local/include/json/*
/usr/local/include/json/json_c_version.h:#define JSON_C_VERSION "0.10.99"

PostGIS built from SVN trunk:

config.status: executing libtool commands
config.status: executing po-directories commands

  PostGIS is now configured for x86_64-unknown-linux-gnu

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

 -------------- Dependencies -------------- 
  GEOS config:          /usr/local/bin/geos-config
  GEOS version:         3.4.0dev
  GDAL config:          /usr/local/bin/gdal-config
  GDAL version:         1.10.0
  PostgreSQL config:    /usr/bin/pg_config
  PostgreSQL version:   PostgreSQL 9.1.8
  PROJ4 version:        47
  Libxml2 config:       /usr/bin/xml2-config
  Libxml2 version:      2.7.8
  JSON-C support:       yes
  PostGIS debug level:  0
  Perl:                 /usr/bin/perl

 --------------- Extensions --------------- 
  PostGIS Raster:       enabled
  PostGIS Topology:     enabled

 -------- Documentation Generation -------- 
  xsltproc:             /usr/bin/xsltproc
  xsl style sheets:     /usr/share/xml/docbook/stylesheet/nwalsh

PostGIS library failes to load due to symbol missing form json-c:

$ psql -d rasters
psql (9.1.8)
Type "help" for help.

rasters=# select * from pg_available_extensions where name like 'postgis%';
          name          | default_version | installed_version |                               comment                               
 postgis_topology       | 2.1.0SVN        |                   | PostGIS topology spatial types and functions
 postgis_tiger_geocoder | 2.1.0SVN        |                   | PostGIS tiger geocoder and reverse geocoder
 postgis                | 2.1.0SVN        |                   | PostGIS geometry, geography, and raster spatial types and functions
(3 rows)

rasters=# create extension postgis;
ERROR:  could not load library "/usr/lib/postgresql/9.1/lib/": /usr/lib/postgresql/9.1/lib/ undefined symbol: json_tokener_errors

Possibly, json-c incompatibility issue.

Attachments (1)

json-c.patch (2.5 KB) - added by kashif 4 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 Changed 4 years ago by strk

I belive you need libjson0-dev, can you confirm that works ?

comment:2 Changed 4 years ago by mloskot

Not sure what you mean, I do canonical

./configure && make && make install

No packages involved.

comment:3 Changed 4 years ago by strk

I was referring to your "couldn't find .deb packages". I guess this one is a problem of compatibility, which requires to try at finding some version string in the header file. Can you help with that ? I don't have the new json-c from git. The author promised he would have exposed a version string, there's a ticket on github for that, started by me.

comment:4 Changed 4 years ago by kashif

It could also be that because he's using the git version, it does not have json_tokener_errors[] as a public api, but instead the new api is to use the json_tokener_error_desc(...) method.

So we will need to check that when this happens in the official json-c release. But for now, we would suggest that you remove your installation of json-c and use the official one from ubuntu via: sudo apt-get install libjson0-dev

I hope this helps!

Changed 4 years ago by kashif

Attachment: json-c.patch added

comment:5 Changed 4 years ago by kashif

Another issue is that the new release of json-c (0.11) has the issue that the name of the library has changed to and the header files are now in include/json-c.

The patch will now look for the new locations and names.

comment:6 Changed 4 years ago by pramsey

This is a no-go:

JSON_LDFLAGS="-ljson-c -ljson"

at least for me, I only have a libjson, so the linker complains that it cannot find a libjson-c

comment:7 Changed 4 years ago by dustymugs

Could we change configure to adapt to libjson > 0.9?

comment:8 Changed 4 years ago by robe

I haven't had trouble compiling against jsoon-c (0.11) by explicitly specifying


What's wrong with keeping that?

comment:9 Changed 4 years ago by mbrennan

I was able to get Postgis 2.1 working by using the json-c 0.10 build (

comment:10 Changed 4 years ago by robe

oops nevermind what I said. I just checked and realized I was testing json-c.0.10 not 0.11

comment:11 Changed 4 years ago by strk

Do you need both -ljson-c _and_ -ljson with libjson > 0.9 ? In any case the patch (which is on the right track) should be adapted to work with json <= 0.9 too

comment:12 Changed 4 years ago by kashif

yes actually you dont need it as you can see from the comments here:

So linking to the orignal -ljson should theoretically work, since libjson loads the newer one. The isssue is that the autoconf cannot find the methods it needs, since they have moved to the newer libjson-c lib. So a solution would be to look for the methods in the newer lib, but still link to the older named one... and that should fix it...

comment:13 Changed 4 years ago by strk

Yep, you could look first in the old, if it fails look in the new, and in both cases link to the old. I'm guessing here that putting the new library into the 5th arg of AC_CHECK_LIB (other-libraries -- would error out when configuring against old libjson.

comment:14 in reply to:  13 Changed 4 years ago by kashif

ok, so should i do this? or someone else is assigned? i have to run home, but i can look at it by tomorrow.

comment:15 Changed 4 years ago by strk

We 0.9'ers have no rush, things work fine for us :P Happy to give your new patch a try tomorrow, thank you !

comment:16 Changed 4 years ago by kashif

Ok have a look at this:

I have replaced the detection by using the pkg-config. Is that a good solution?

The diff if you want to apply it is:

comment:17 Changed 4 years ago by strk

The patch drops --without-json and --with-jsondir, which makes it not an option for 2.1.0. Could you please try this one : Please report output of ./configure | grep json

comment:18 Changed 4 years ago by strk

The patch inline (so it lasts longer):

diff --git a/ b/
index 80d31b5..bcc9a10 100644
--- a/
+++ b/
@@ -789,7 +789,9 @@ CPPFLAGS="$CPPFLAGS_SAVE"
 dnl Ensure we can link against libjson
-AC_CHECK_LIB([json], [json_object_get], [HAVE_JSON=yes], [], [])
+AC_CHECK_LIB([json], [json_object_get], [HAVE_JSON=yes], [
+  AC_CHECK_LIB([json-c], [json_object_get], [HAVE_JSON=yes], [], [])
+], [])
 if test "$HAVE_JSON" = "yes"; then

comment:19 Changed 4 years ago by kashif

Yes so that's what I tried initially, a one line change:

-AC_CHECK_LIB([json], [json_object_get], [HAVE_JSON=yes], [], []) +AC_SEARCH_LIBS([json_object_get], [json-c json], [HAVE_JSON=yes], [], [])

And it finds the newer json-c, but when compiling I get a linker error:

$ make .... st_2d.o gserialized_gist_nd.o gserialized_estimate.o geography_inout.o geography_btree.o geography_measurement.o geography_measurement_trees.o geometry_inout.o -L/usr/local/Cellar/postgresql/9.2.4/lib -L/usr/local/Cellar/ossp- uuid/1.6.2/lib -Wl,-dead_strip_dylibs ../libpgcommon/libpgcommon.a ../liblwgeom/.libs/liblwgeom.a -L/usr/local/Cellar/geos/3.3.8/lib -lgeos_c -lproj -ljson -lxml2 -bundle_loader /usr/local/Cellar/postgresql/9.2.4/bin/postgres Undefined symbols for architecture x86_64:

"_json_object_array_get_idx", referenced from:

_parse_geojson in liblwgeom.a(lwin_geojson.o) _parse_geojson_coord in liblwgeom.a(lwin_geojson.o)

"_json_object_array_length", referenced from:

... ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: * [] Error 1 make: * [all] Error 1

and it seems that the -Wl,-dead_strip_dylibs flag is striping out the libjson-c which is linked into the the older libjson shared lib:

$ otool -L libjson.0.dylib libjson.0.dylib:

/usr/local/lib/libjson.0.dylib (compatibility version 2.0.0, current version 2.0.0) /usr/local/lib/libjson-c.2.dylib (compatibility version 3.0.0, current version 3.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

I have an issue about it on github:

Hope this helps.

comment:20 Changed 4 years ago by strk

Please try with r11560 (trunk). It's been tested with 0.9 by me and 0.10 by dustymugs. I think this one could go in 2.1 too

comment:21 Changed 4 years ago by dustymugs

Minor edit. I'm testing with 0.11.

comment:22 Changed 4 years ago by kashif

the issue with 0.11 is what i described above... let me know if it works for you dustymugs. thanks!

comment:23 Changed 4 years ago by strk

Resolution: fixed
Status: newclosed

Committed to 2.1 branch as r11561 Please reopen if it still fails (it worked for dustymugs)

comment:24 Changed 4 years ago by dustymugs

Everything works for me on 2.1 and -trunk (2.2)

comment:25 Changed 4 years ago by robe

Milestone: PostGIS 2.1.0
Resolution: fixed
Status: closedreopened

I haven't had a chance to test thsi since I'm still building up my mignw 4.8 chain however winnie doesn't seem satisfied with these changes.

/liblwgeom.a  -L/c/jenkins/geos/rel-3.4.0devw64/lib -L/c/ming64/projects/proj/rel-4.8.0w64/lib -lgeos_c -lproj -ljson -L/c/ming64/projects/libxml/rel-libxml2-2.7.8w64/lib -lxml2 -lws2_32  -Lc:/jenkins/POSTGR~1/rel/PG9~3.2W6/lib -lpostgres
c:/ming64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.5.4/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ljson
collect2: ld returned 1 exit status
c:\ming64\mingw64\bin\dllwrap.exe: c:\ming64\mingw64\bin\gcc exited with status 1

comment:26 Changed 4 years ago by robe

Forgot to ask are we still using json dir configure as I said it still needs to respect that for 2.1. One thing that is different between debbie and winnie is that debbie I installing json using apt-get where as winnie passes this thru the json dir setting and she also has json statically compiled into postgis library.

comment:27 Changed 4 years ago by strk

Uhm, the patch only adds a check for libjson-c, and if present it uses that one. I guess in your case that test is finding a libjson-c in a place you did NOT want postgis to find. How do you tell winnie to link json statically ?

comment:28 Changed 4 years ago by robe

I build json as a static library instead of shared. In 0.9 it naturally does that for under mingw, in 0.10 I build with --disable-shared --enable-static. Anyrate I think its dangerous to assume people have only one version of libjson on their system especially for package maintainers where they DON'T necessarily want the one installed in default system folder used. That's what I thought the point is of having the --with-jsondir option.

If we can't fix this this change has to be backed out of 2.1.

comment:29 Changed 4 years ago by strk

Robe, so do you have a custom libjson-0.9 in the dir specified using --with-jsondir and a libjson-0.10+ in a standard library dir ? The code isn't actually assuming you have one, but for some reason it's failing to use -L, are you sure you did use a --with-jsondir option ? The patch doesn't drop that.

Could you paste the full ./configure invocation and the output lines matching "json" ?

comment:30 Changed 4 years ago by strk

Ah, I see the problem now, the patch is overriding JSON_LDFLAGS after the code block handling --with-jsondir is setting it. In turn we're overriding it to workaround the osX bug

comment:31 Changed 4 years ago by strk

r11563 should fix --with-jsondir (in trunk). Please test and let me know. If everyone is happy this will need to be backported in 2.1 branch.

comment:32 Changed 4 years ago by robe

Peeked in on winnie's regression paces and that seems to have fixed her complaints. I'd go ahead and commit to 2.1 even though she's not done testing 2.2.

comment:33 Changed 4 years ago by strk

Resolution: fixed
Status: reopenedclosed

r11564 backports this to 2.1 branch

Note: See TracTickets for help on using tickets.