libgeotiff lesson for today

Doing final tests of libLAS on Linux (Ubuntu 7.04), before Hobu will release 1.0.0, I attempted to build it with latest libgeotiff 1.2.5. I moved my fingers on keyboard and did ./configure && make, shortly then I saw strange looking error message:

/usr/bin/ld: makegeo: hidden symbol `__stack_chk_fail_local' in /usr/lib/libc_nonshared.a(stack_chk_fail_local.oS) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status

Google is your friend, so in a few seconds I knew what’s going wrong. ./configure sets Makefile to call ld -shared. However, it does not work with GCC 4, because ld linker does not include all required references to other shared libraries. Simply, GCC linker driver seems to handle shared references better, than bare ld.

The conclusion is, that if you use GCC 4.x and you want to build libgeotiff, configure it this way:

./configure --with-ld-shared="gcc -shared"

Update July 31, 2008: Another solution is to add -fno-stack-protector option to CFLAGS and CXXFLAGS. Regarding Ubuntu Linux, this issue seems to be related to enabled SSP support (see also Ubuntu Wiki) available in GCC 4.1.

libgeotiff 1.2.5

libgeotiff 1.2.5 has been released.

Libgeotiff is an open source library normally hosted on top of libtiff for reading, and writing GeoTIFF information tags.

As officially announced, the new version includes a few bug fixes and improvements, coordinate systems dictionaries have been updated to EPSG 6.17 dataset.

There is also a new feature called Simple Tags Interface to make it easier to use libgeotiff to process geotiff tags in other file format. This new interface is used in libLAS to support LAS files georeferencing.

Packages of libgeotiff 1.2.5 are hosted on OSGeo Download server:
http://download.osgeo.org/geotiff/libgeotiff/

A week ago, Frank Warmerdam proposed to make GeoTIFF a subproject of OSGeo MetaCRS project, because of a few reasons:

  • libgeotiff is primary about CRS management
  • it is too small project to join OSGeo on it’s own
  • EPSG handling provided by libgeotiff is foundational number of FOSS4G projects (GDAL, QGIS, PROJ.4 and PostGIS, libLAS)

Motion: Libgeotiff as a MetaCRS sub-project was not waiting long and eventually has gained full acceptance from Project Steering Committee of MetaCRS, means passed.

Since July 28, 2008 GeoTIFF project is now a part of MetaCRS initiative lead by OSGeo community.

Juggling SVN keywords

When working in a team and maintaining large source code repositories, it’s easy to forget to set svn:keywords property for newly added file or update the property when adding new keywords to files.

The first solution that may come to once mind is to involve cron job or define post-commit hook. The former is easier to setup but may be unsafe if commits are allowed by authenticated users. The second option seems appealing as we can avoid authentication problems, but it’s generally not recommended to set properties from a hook. See warning in red frame in the Hook Scripts chapter of the SVN book.

After short discussion with folks on #gdal IRC channel, we have came to the conclusion that the easiest and safest option will be to periodically run a script fixing the svn:keywords where needed. Such script will be executed by team members on their local machines and against working copy of GDAL sources. This way we assure that the commit process is well authenticated and under human control :-)

So, here is the script – svnkeywords.sh (backed up here here):

$ ./svnkeywords $HOME/dev/gdal/_svn/trunk
Entering '/home/mloskot/dev/gdal/_svn/trunk'
Setting svn:keywords property........done.

It is quite generic and can run against any sources tree maintained by Subversion. The only requirement is Unix OS with toolset like /bin/sh, find and grep. Happy using!

Yet another argument for -Wall always on

Yes, I’m religious about writing correct and standard C/C++ code and the decalogue of my religion tells do not ignore compiler warnings. Yet another pinch to the vast jar of examples is about getting detailed warning on mixed types in printf format specifiers:

#include <stdio .h>
int main (void)
{
printf ("%d", 0.0);
printf ("%lu", 0u);
printf ("%lu", sizeof 0);
return 0;
}

Building the test above with following three commands will answer why it’s a good idea to help the compiler to help us: