[RASTER] regress tests on 'loader' fail

[kain]

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

2. 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

3. ll /usr/lib64/libstdc++.so.6 /usr/lib64/libstdc++.so.6 → libstdc++.so.6.0.8

4. 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

2. libgdal, libgeos are compiled with newer GLIBCXX of this GCC

3. 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?

[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

[kain]

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.

[kain]

I found a similar ticket in PostGIS trac:

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

[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)

[kain]

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.

[kain]

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.),

[kain]

Thanks to @dustymugs too

[kain]

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.