patch for building gdal on AIX

[zhenchen17]

Patch for building gdal on AIX. There is two minor modification:

1. frmts/ers/ersdataset.cpp

explicit cast CPLString to const char * which can't be done by xlC compiler

2. ogr/ogrsf_frmts/shape/shpopen.c

There is a redefinition of int32 datatype. AIX system header files inttype.h defines it. As a workaround, The modification just simply check if the header is include before(_H_INTTYPES macro). For a further task, it should be detected automatically by autoconf scriptes or similar tools.

Hope this could help anyone who struggling with gdal against AIX platform.

[Even Rouault]

I've applied in trunk (r24927) the fix in ERS driver.

As far as shpopen.c, I'm not sure what Frank would prefer. The "#ifndef _H_INTTYPES" test doesn't look very AIX specific, so perhaps there are platforms that would define _H_INTTYPES but not int32. I'm wondering if we should not just remove the logic to support 16-bit platforms... and use plain "unsigned int" ?

[zhenchen17]

Replying to rouault:

As far as shpopen.c, I'm not sure what Frank would prefer. The "#ifndef _H_INTTYPES" test doesn't look very AIX specific, so perhaps there are platforms that would define _H_INTTYPES but not int32. I'm wondering if we should not just remove the logic to support 16-bit platforms... and use plain "unsigned int" ?

I generated another patch for AIX compiling which added int* and uint* data type checking by automake tools. I think it would be better to define HAVE_INT32 macro for indicating int32 data type has been defined in system header file. These macros are defined in cpl_config.h which is included by cpl_port.h. Which means almost every file accepts these macros.

The final segement looks like :

#ifndef HAVE_INT32

typedef long int32;

#endif /* HAVE_INT32 */

I didn't commit configure file produced by configure.in for there is a lot difference. Please re-generate it for testing.

[zhenchen17]

AIX patch2

[Markus Neteler]

I'm struggling, too, on AIX 7.1, using 1.10.svn. The proposed patches seem to be relevant. I take liberty to change to "bug" since the compilation currently fails without changes in the source code.

[zhenchen17]

Replying to neteler:

I'm struggling, too, on AIX 7.1, using 1.10.svn. The proposed patches seem to be relevant. I take liberty to change to "bug" since the compilation currently fails without changes in the source code.

Thanks for your comment. And glad to someone else is struggling with gdal on AIX :), a forgotten platform. You are free to discuss here. Also hope the patch could be applied to svn ASAP.

[Even Rouault]

Regarding "hope the patch could be applied to svn ASAP", this is unfortunately not as simple as that since the changes are not all in the GDAL own files but in upstream projects : some are in libtiff, others in shapelib, others in PCIDSK SDK. I'm dropping me as owner of this bug, being not a commmiter of those projects.

[Markus Neteler]

Just FYI: In SQLite3 things are handled slightly differently, perhaps interesting for inspiration:

# on AIX 7.1:
sh configure
...
checking for inttypes.h... yes     <<--- the same but selectively tested below:
...
checking for _LARGE_FILES value needed for large files... 1
checking for int8_t... yes
checking for int16_t... yes
checking for int32_t... yes
checking for int64_t... yes
checking for intptr_t... yes
checking for uint8_t... yes
checking for uint16_t... yes
checking for uint32_t... yes
checking for uint64_t... yes
checking for uintptr_t... yes
...

[zhenchen17]

Replying to rouault:

Regarding "hope the patch could be applied to svn ASAP", this is unfortunately not as simple as that since the changes are not all in the GDAL own files but in upstream projects : some are in libtiff, others in shapelib, others in PCIDSK SDK. I'm dropping me as owner of this bug, being not a commmiter of those projects.

I don't think it is complex to fix. Patches are aiming at cross platform compile issues which I think harmless to the existing code, except the PCDisk driver. I can understand each library has its own data type definition, and avoid cross platform issues. But it would be better if using data type in CPL port. We can do data type test in auto tools, to avoid conflict with system definition. The macros are used for this. All types are needed.

[warmerdam]

I'll try to take a look in the next few days. Poke me within a week (in this ticket) if there is no action. I'm always surprised though to see AIX still in use!

I hate to see the explicit use of .c_str() - is it really needed? I wonder why there but not everywhere.

[zhenchen17]

Replying to warmerdam:

I'll try to take a look in the next few days. Poke me within a week (in this ticket) if there is no action. I'm always surprised though to see AIX still in use!

I hate to see the explicit use of .c_str() - is it really needed? I wonder why there but not everywhere.

I also hate AIX, too, who get used to Linux. But there are a lot of requests from IBM buyers who have to use this system.

The explicit cast of .c_str() is not necessary though, static_cast or c-like cast(const char*) is working. If nothing adds to the string, the stupid compiler will complain a lot and do not know how to convert to a const char *(even there is an operator to const char*). What I suggest is to use a cpp style cast which looks like:

osProj.size() ? static_cast<const char*>(osProj) : "RAW"

better?

[zhenchen17]

Replying to warmerdam:

I'll try to take a look in the next few days. Poke me within a week (in this ticket) if there is no action. I'm always surprised though to see AIX still in use!

I hate to see the explicit use of .c_str() - is it really needed? I wonder why there but not everywhere.

As a reminder about a week, as your request. :-)

[Markus Neteler]

I have documented my experience on AIX 7.x here:

​http://grasswiki.osgeo.org/wiki/Talk:Compile_and_Install#AIX_7.x_compilation_hints

--> conf_gdal.sh:

The current 1.10.svn requires a manual edit of "port/cpl_config.h" to disable the use of AIX's <inttypes.h> header file. GDAL compiles when setting it to 0;

#define HAVE_INTTYPES_H 0

[Even Rouault]

If someone can contribute a small non-invasive no-brainer patch, reopen the ticket with it. Otherwise let's forget AIX...