[MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version

[Ian MacArthur]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


Upload Michael Baeuerle's patches to implement a scandir() function that we
can use on *nix systems that is free of any potential license restrictions.

The prior fl_scandir method was removed by #2687 due to license concerns,
but this broke compilation on some systems (e.g. SunOS 5.7) that do not
provide a suitable scandir() function natively.

Attached files implement a substitute that we can use, that is reported to
work, and should not break any exisitng platforms.


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Ian MacArthur]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


Currently tested on the following systems:
----------------------------------------------------------------------
Windows:
- WinXP with mingw32 (assume other WinXX versions OK, since code change is
trivial here)

OSX:
- 10.6.8 (OSX post 10.8 has a different scandir() implementation so needs
to be verified separately)

Systems with no usable native 'scandir()':
- SunOS 5.7 (64Bit, big endian)

Systems with a native POSIX.1-2008 compliant 'scandir()':
- F17, 32-bit
- Ubuntu 12.10, 32-bit
(this codepath is effectively unchanged from before)

OSF/DU/Tru64/IRIX:
- None yet

AIX:
- None yet

Systems with native 'scandir()', but not a POSIX.1-2008 compliant one
(plus it matches to none of the explicitly handled cases above):
- GNU/Linux with glibc 2.8 (32Bit, little endian)
- NetBSD 5.1 (32Bit, little endian)


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Manolo Gouy]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


The patch is also OK with Mac OS X 10.8


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Albrecht Schlosser]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


Added a patch file to replace the full source files in the uploaded tar
file. The patch is against current svn (r 9827). Although bigger than the
compressed tar file, I prefer the patch format.

The patch contains a few small changes WRT the tar file:

- copyright year adjusted (e.g. "1998-2010, 2013" -> "1998-2013"
- fixed one typo

Still testing, but patch looks good AFAICT. I'll post my test results with
Cygwin and other available systems later, but this can take some days due
to restricted test time. :-(


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Albrecht Schlosser]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


I'm not sure whether adding "const" to some function prototypes would break
the ABI, but I believe it doesn't. Should be checked though...


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Greg Ercolano]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


I applied Albrecht's patch to a fresh copy of fltk r9827,
and FLTK built on IRIX 6.5 OK, so looks good to me.
(IRIX has its own implementation of scandir(), and HAVE_SCANDIR
was set to 1 in config.h)

There were a bazillion "remarks" from the compiler while building FLTK
(nothing new; it /always/ moans about unused variables and unreached
code), but nothing related to the patch. And nothing stopped the compiler.

Just to be sure I didn't miss anything in the voluminous "remarks"
warnings, I tried rebuilding just filename_list.o and scandir.o
by themselves, and there were no remarks or warnings at all.

So you can add IRIX 6.5 to your list.


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Ian MacArthur]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


ALbrecht queried whether there are any ABI issues: Micha reports that it
looks like there are.

In particular, the change of the prototypes of the sorting functions to be
more const-correct breaks C++ linkage.

Options are perhaps to revert the functions to their previous non-const
forms?

Greg suggests that we could keep the new forms if we put the ABI guards
around them, with the old forms being the default...

The new forms are preferred though because they are a better match to the
Posix spec.

In other, happier, news, Micha reports that the code runs fine on:
----------------------------------------------------------------------
POSIX.1-2008 compliant native 'scandir()':
- HP-UX 11.11 (32Bit, big endian)

Special AIX native 'scandir()':
- AIX 5.1 (32Bit, big endian)
----------------------------------------------------------------------

And Manolo has verified that the special detection of MacOS >=10.8 still
works.


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current

[Albrecht Schlosser]

DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current


Regarding ABI issues WRT (C++) fl_filename_list(), Michael wrote:

"I have tried to statically link code that use the new 'filename.H'
against an older library and this fails because the parameter types of
the C++ function do not exactly match."

This is not the really the ABI problem we're talking about. If you compile
with a new library (i.e. its header files), then this is NOT supposed to
link and work correctly with an older library.

The important part is the other way around: if you have an old program,
linked dynamically against an older library (Windows DLL, U*X shared
object), THEN it must still work with a newer shared library. This means
that all previously existing functions/methods must still exist in the new
library and be compatible.

Michael continued:
"... is it possible to overload the function declaration without breaking
other things?"

I know that we have such overloaded functions/methods with different
const-ness in some parameters. So, in theory, it should work if we kept
the old non-const (C++) function name(s) and add another const-correct
version, maybe as a pure C function (wasn't this another change you,
Michael, did?). This could probably work, but I'm not absolutely sure.
In this case the old function can simply call the new function, if this is
possible (maybe by casting the arguments).

Hint: a *test* could be to compile and _link_ a program dynamically with
an old shared library and _run_ it (maybe on another system) with the new
shared library. That's what typically happens if you have built your
program on a Linux system with fltk 1.3.0, then you upgrade the system,
and this installs fltk 1.3.3 (the next version, maybe with this patch).


Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current