Opened 10 years ago
Closed 10 years ago
#2213 closed defect (fixed)
postgis-2.1.so: undefined symbol: json_tokener_errors
|Reported by:||mloskot||Owned by:||pramsey|
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 dblatex: convert: mathml2.dtd: http://www.w3.org/Math/DTD/mathml2/mathml2.dtd
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/postgis-2.1.so": /usr/lib/postgresql/9.1/lib/postgis-2.1.so: undefined symbol: json_tokener_errors
Possibly, json-c incompatibility issue.
Change History (34)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Not sure what you mean, I do canonical
./configure && make && make install
No packages involved.
comment:3 by , 10 years ago
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 by , 10 years ago
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!
by , 10 years ago
comment:5 by , 10 years ago
Another issue is that the new release of json-c (0.11) has the issue that the name of the library has changed to libjson-c.so and the header files are now in include/json-c.
The patch will now look for the new locations and names.
comment:6 by , 10 years ago
This is a no-go:
at least for me, I only have a libjson, so the linker complains that it cannot find a libjson-c
comment:7 by , 10 years ago
Could we change configure to adapt to libjson > 0.9?
comment:8 by , 10 years ago
I haven't had trouble compiling against jsoon-c (0.11) by explicitly specifying
What's wrong with keeping that?
comment:9 by , 10 years ago
I was able to get Postgis 2.1 working by using the json-c 0.10 build (https://github.com/json-c/json-c/tree/json-c-0.10)
comment:10 by , 10 years ago
oops nevermind what I said. I just checked and realized I was testing json-c.0.10 not 0.11
comment:11 by , 10 years ago
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 by , 10 years ago
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…
follow-up: 14 comment:13 by , 10 years ago
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 — http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Libraries.html) would error out when configuring against old libjson.
comment:14 by , 10 years ago
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 by , 10 years ago
We 0.9'ers have no rush, things work fine for us Happy to give your new patch a try tomorrow, thank you !
comment:16 by , 10 years ago
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 by , 10 years ago
The patch drops —without-json and —with-jsondir, which makes it not an option for 2.1.0.
Could you please try this one : http://strk.keybit.net/tmp/jsonc.patch
Please report output of
./configure | grep json
comment:18 by , 10 years ago
The patch inline (so it lasts longer):
diff --git a/configure.ac b/configure.ac index 80d31b5..bcc9a10 100644 --- a/configure.ac +++ b/configure.ac @@ -789,7 +789,9 @@ CPPFLAGS="$CPPFLAGS_SAVE" dnl Ensure we can link against libjson LIBS_SAVE="$LIBS" LIBS="$JSON_LDFLAGS" -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], , ) +], ) LIBS="$LIBS_SAVE" if test "$HAVE_JSON" = "yes"; then
comment:19 by , 10 years ago
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: * [postgis-2.2.so] 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: https://github.com/json-c/json-c/issues/79
Hope this helps.
comment:20 by , 10 years ago
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 by , 10 years ago
Minor edit. I'm testing with 0.11.
comment:22 by , 10 years ago
the issue with 0.11 is what i described above… let me know if it works for you dustymugs. thanks!
comment:23 by , 10 years ago
|Status:||new → closed|
Committed to 2.1 branch as r11561 Please reopen if it still fails (it worked for dustymugs)
comment:24 by , 10 years ago
Everything works for me on 2.1 and -trunk (2.2)
comment:25 by , 10 years ago
|Milestone:||→ PostGIS 2.1.0|
|Status:||closed → reopened|
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
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 by , 10 years ago
|Status:||reopened → closed|
r11564 backports this to 2.1 branch
I belive you need libjson0-dev, can you confirm that works ?