Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#3089 closed defect (invalid)

[RASTER] regress tests on 'loader' fail

Reported by: kain Owned by: Bborie Park
Priority: medium Milestone: PostGIS 2.1.7
Component: raster Version: 2.1.x
Keywords: Cc:

Description

I cannot pass the regression tests of raster loader, given error:


loader/Basic .. failed (test: running raster2pgsql: /tmp/pgis_reg/loader.err) loader/BasicCopy .. failed (test: running raster2pgsql: /tmp/pgis_reg/loader.err) loader/BasicFilename .. failed (test: running raster2pgsql: /tmp/pgis_reg/loader.err)

in /tmp/pgis_reg/loader.err,


/home/kain/postgis-2.1.5/regress/../raster/loader/raster2pgsql: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/local/lib/libgdal.so.1)

/home/kain/workspace/metro/cdb-pg/contrib/postgis-2.1.5/regress/../raster/loader/raster2pgsql: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by /usr/local/lib/libgeos-3.4.2.so)

/home/kain/postgis-2.1.5/regress/../raster/loader/raster2pgsql: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/local/lib/libgeos-3.4.2.so)

Environments:


  1. Rhel 5, PostgreSQL 9.3.5, PostGIS 2.1.5
  1. GCC gcc -print-libgcc-file-name

/opt/gcc-4.4.2/lib/gcc/x86_64-unknown-linux-gnu/4.4.2/libgcc.a

ll /opt/gcc-4.4.2/lib64/libstdc++.so.6

/opt/gcc-4.4.2/lib64/libstdc++.so.6 → libstdc++.so.6.0.13

  1. ll /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6 → libstdc++.so.6.0.8
  1. libtool # Run-time system search path for libraries

sys_lib_dlsearch_path_spec="/lib64 /usr/lib64 "

I guess:


  1. I've download a separated GCC
  1. libgdal, libgeos are compiled with newer GLIBCXX of this GCC
  1. while raster2pgsql searches for the older GLIBCXX of the system's.

Remark:


I have not met this issue in PostGIS 2.1.4 and earlier versions. It occurs on PostGIS 2.1.5. Any suggestions for me?

Change History (8)

comment:1 by Bborie Park, 8 years ago

Resolution: invalid
Status: newclosed

This question is better asked in the postgis-users ML.

It looks like libgdal and libgeos cannot find your different glibc libraries. You may need to recompile everything to your current glibc

in reply to:  1 comment:2 by kain, 8 years ago

Replying to dustymugs:

This question is better asked in the postgis-users ML.

It looks like libgdal and libgeos cannot find your different glibc libraries. You may need to recompile everything to your current glibc

Thanks for your valuable suggestions. I'm not sure whether should I re-submit it to postgis-users ML, because, at the same version, PostGIS/loader have not met this issue, but PostGIS/Raster/loader met separately. But I'll try to re-compile libgdal.

Now my solution is: remove /lib/lib64 from the relink_command of “raster2pgsql”, then everything is OK.

comment:3 by kain, 8 years ago

I found a similar ticket in PostGIS trac:

http://trac.osgeo.org/postgis/ticket/3067

comment:4 by robe, 8 years ago

kain,

I think the reason regular PosttGIS/loader doesn't have the same issue is because as I recall it's a pure C library and doesn't rely on GEOS (which is C++). Anyway glad to see you were able to find a workaround. As a general rule, I try to avoid compiling GDAL with geos. Creates a big mess also when you try to upgrade GEOS without recompiling GDAL (from what I remember — I think pramsey has experienced that unpleasantness to)

in reply to:  4 comment:5 by kain, 8 years ago

Replying to robe:

kain,

I think the reason regular PosttGIS/loader doesn't have the same issue is because as I recall it's a pure C library and doesn't rely on GEOS (which is C++). Anyway glad to see you were able to find a workaround. As a general rule, I try to avoid compiling GDAL with geos. Creates a big mess also when you try to upgrade GEOS without recompiling GDAL (from what I remember — I think pramsey has experienced that unpleasantness to)

Thanks Robe, you are right, PostGIS/loader is pure C library, they are different. I'm discussing with our releng engineers to find a general way to compile GDAL and GEOS across multiple platforms.

in reply to:  4 comment:6 by kain, 8 years ago

Replying to robe:

kain,

As a general rule, I try to avoid compiling GDAL with geos. Creates a big mess also when you try to upgrade GEOS without recompiling GDAL (from what I remember — I think pramsey has experienced that unpleasantness to)

Thanks to Robe for your useful suggestion, I re-compile these dependent libraries and maintain their path in controllable way (other than default/blindly). Now I've deployed Raster on our Greenplum Database (from EMC & Pivotal Inc.), :)

comment:7 by kain, 8 years ago

Thanks to @dustymugs too :)

comment:8 by kain, 8 years ago

Recently I found another two ways to bypass this issue:

  1. remove /usr/lib64/libexpat.la from gdal's dependent liararies, otherwise libtool dynamically loads /usr/lib64 rather than /opt/gcc-4.4.2/lib64 when builds the raster/loader;
  2. remove those *.a and *.la files in gdal/lib/, then libtool may automatically search for the dependent .so files.

With above methods, we can compile raster with a separate GCC version (different from the default GCC provided by OS).

Wish this helps to other guys.

Note: See TracTickets for help on using tickets.