Blame extension/README.fts

Packit Service f629e6
Wed Aug 29 22:34:24 IDT 2012
Packit Service f629e6
============================
Packit Service f629e6
Packit Service f629e6
Portability is a myth, a chimera. Like the pot of gold at the end of
Packit Service f629e6
the rainbow, it's always looks like it is just within your reach, but
Packit Service f629e6
in fact, it is seldom, if ever, truly acheivable.
Packit Service f629e6
Packit Service f629e6
It all started when trying to get the extensions to work on my aged
Packit Service f629e6
PowerPC Macbook G4 running Mac OS X 10.5.  That machine is wonderful,
Packit Service f629e6
since it is neither an Intel architecture machine nor is it GNU/Linux;
Packit Service f629e6
two criteria that are becoming increasingly harder to meet over 10%
Packit Service f629e6
into the 21st century.
Packit Service f629e6
Packit Service f629e6
The readdir extension didn't work. Furthermore, GDB showed that in gawk
Packit Service f629e6
itself, struct stat had one size and layout, while inside the readdir
Packit Service f629e6
code, it had another.
Packit Service f629e6
Packit Service f629e6
This turned out to be due to the large file nonsense foisted off upon
Packit Service f629e6
us by POSIX. The main gawk configure.ac had AC_SYS_LARGEFILE but the
Packit Service f629e6
extensions' configure.ac did not.  OK - a one line fix, rebuild, and
Packit Service f629e6
everything is OK.  Right?
Packit Service f629e6
Packit Service f629e6
Of course not.
Packit Service f629e6
Packit Service f629e6
Everything was OK on my 64-bit GNU/Linux Intel system, but lo and behold,
Packit Service f629e6
I compiled on a 32-bit GNU/Linux system and suddenly the fts tests
Packit Service f629e6
stopped working. A look at the config.log reveals:
Packit Service f629e6
Packit Service f629e6
	<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64
Packit Service f629e6
Packit Service f629e6
Why? Who knows. The comment in the file itself is cryptic:
Packit Service f629e6
Packit Service f629e6
	/* The fts interface is incompatible with the LFS interface which
Packit Service f629e6
	   transparently uses the 64-bit file access functions.  */
Packit Service f629e6
	#ifdef __USE_FILE_OFFSET64
Packit Service f629e6
	# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
Packit Service f629e6
	#endif
Packit Service f629e6
Packit Service f629e6
It purports to be English, but says nothing intelligible, and the man
Packit Service f629e6
page sheds no light, either.
Packit Service f629e6
Packit Service f629e6
Fortunately, the source for fts from NetBSD is reasonably legible,
Packit Service f629e6
freely available, and has a usable license.
Packit Service f629e6
Packit Service f629e6
So, I try to just plug it in directly.  Everything compiles, nothing
Packit Service f629e6
works. There is shared library / weird linker dark voodoo crap going on.
Packit Service f629e6
Packit Service f629e6
*I* am not a powerful enough Jedi to get around it, and I think it has
Packit Service f629e6
more to do with the Dark Side of the Force than with the Light Side. So
Packit Service f629e6
gawkfts.h now has:
Packit Service f629e6
Packit Service f629e6
	#define fts_children gawk_fts_children
Packit Service f629e6
	#define fts_close gawk_fts_close
Packit Service f629e6
	#define fts_open gawk_fts_open
Packit Service f629e6
	#define fts_read gawk_fts_read
Packit Service f629e6
	#define fts_set gawk_fts_set
Packit Service f629e6
Packit Service f629e6
to rename things, and it all compiles and works.
Packit Service f629e6
Packit Service f629e6
The Plan 9 guys got it right when they threw eveything out and started
Packit Service f629e6
over again. I sure wish I could.
Packit Service f629e6
Packit Service f629e6
On the bright side, this is stuff that would have had to be done anyway
Packit Service f629e6
for at least MinGW, and maybe for some other systems. So it's not wasted
Packit Service f629e6
effort. But it sure is sad that it's necessary.
Packit Service f629e6
Packit Service f629e6
Arnold Robbins
Packit Service f629e6
arnold@skeeve.com