FTBFS: PowerPC build fails choking on half a million lines of assembly

[Ben Collins]

Dear author, please redo the epsg_update tool to create the epsg_inline.c file in multiple files (that get compiled separately, not #included into srs_init.c).

The build fails because this super large file completely overflows some internal whatever in gcc and the produced assembly will not compile.

This assembly may or may not be broken because of a bug in the compiler, or perhaps a hardware limitation. Either way, I still don't think a 127k+ line generated C file is anything to be proud of :)

Since this file is generated, and you have a C program that does it, I think it should be near trivial to rework it to split the files (based on the initialize_epsg_XX function naming seems like a good splitting point).

Please remember, it should not be #included into one file. The idea is that it needs to split into separately compiled files to reduce the problem (and actually get compiled faster on multi-core systems too).

Thanks!

[Volker (volker-redhat-bugs)]

Doesn't build on ppc64.

 gcc -DPACKAGE_NAME=\"libspatialite\" -DPACKAGE_TARNAME=\"libspatialite\" -DPACKAGE_VERSION=\"2.4.0\" "-DPACKAGE_STRING=\"libspatialite 2.4.0\"" -DPACKAGE_BUGREPORT=\"<email address hidden>\" -DPACKAGE=\"libspatialite\" -DVERSION=\"2.4.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STDIO_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_MATH_H=1 -DHAVE_FLOAT_H=1 -DHAVE_FCNTL_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDDEF_H=1 -DHAVE_STDINT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SQLITE3_H=1 -DHAVE_SQLITE3EXT_H=1 -DHAVE_DLFCN_H=1 -DTIME_WITH_SYS_TIME=1 -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_STRFTIME=1 -DHAVE_MEMSET=1 -DHAVE_STRCASECMP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSTR=1 -DHAVE_FDATASYNC=1 -DHAVE_FTRUNCATE=1 -DHAVE_GETCWD=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MEMMOVE=1 -DHAVE_STRERROR=1 -DHAVE_LIBSQLITE3=1 -DHAVE_PROJ_API_H=1 -DHAVE_GEOS_C_H=1 -DHAVE_ICONV_H=1 -I. -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -I../../src/headers -D_LARGE_FILE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -DNDEBUG=1 -DOMIT_GEOCALLBACKS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mminimal-toc -MT srs_init.lo -MD -MP -MF .deps/srs_init.Tpo -c srs_init.c -fPIC -DPIC -o .libs/srs_init.o
{standard input}: Assembler messages:
{standard input}:128092: Error: operand out of range (0x0000000000008000 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
{standard input}:128111: Error: operand out of range (0x0000000000008008 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
{standard input}:128123: Error: operand out of range (0x0000000000008010 is not between 0xffffffffffff8000 and 0x0000000000007ffc)
{standard input}:128170: Error: operand out of range (0x0000000000008018 is not between 0xffffffffffff8000 and 0x0000000000007ffc)

... and so on, and so on.

Informed upstream here: http://groups.google.com/group/spatialite-users/browse_thread/thread/691e7c9460d8cb81

[Volker (volker-redhat-bugs)]

3.1.0-RC3 builds fine. It will not go into EPEL 6 though, due to the stable policy.

[Launchpad Janitor (janitor)]

This bug was fixed in the package spatialite - 3.1.0~rc2-1ubuntu1

---------------
spatialite (3.1.0~rc2-1ubuntu1) quantal; urgency=low

  * Apply giant patch from upstream to rearrange all the EPSG dataset
    self-initializing code in many small sources, fixing failure to build on
    powerpc (LP: #1012976).
 -- Colin Watson <email address hidden> Tue, 16 Oct 2012 13:47:38 +0100

[Volker (volker-redhat-bugs)]

Added ExcludeArch: ppc64 in 2010, closing.