My concern (as a commercial developer that releases
static builds) is not whether the code is used,
but that it's in the lib at all.
True: if the code is not called, it shouldn't
appear in the linked executables by optimization.
And legally I imagine
On 07/20/11 03:14, Albrecht Schlosser wrote:
On 20.07.2011 10:04, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Agreed, but then we might have to maintain dead code, and given the
complexity of all that #if HAVE_something stuff, i'd like to remove
it for all times...
Suggest we comment out
Suggest we comment out the file and see what happens.
To prevent having to modify all the Makefile/VS files,
I'd recommend we just change the file to be a one line comment
that says '// Removed due to non-LGPL/static license. See
STR# . Original in svn r.'
and
Hmm, can someone check the LGPL header src/scandir.c?
While doing the LGPL header mods for STR #2685,
I noticed this file appears to be part of the GNU C
Library, which may not be compat with the FLTK
static LGPL exception.
This code might need to be re-written.
Hmm, that's odd, I'd
On 19.07.2011 10:51, MacArthur, Ian (SELEX GALILEO, UK) wrote:
Hmm, can someone check the LGPL header src/scandir.c?
...
So... I wonder if we need this at all? WinXX hosts probably need it
(though not cygwin or possibly mingw I suspect) but have their own
host-specific version, but are
AFAICT that would be the only case where this code came
into play, i.e.
on non-WinXX host for which configure could not locate a scandir
implementation at build time...
Yep, I believe this is true. There is an exception for SunOS that
disables the system scandir function explicitly,
On 19.07.2011 14:05, MacArthur, Ian (SELEX GALILEO, UK) wrote:
If we can ascertain that there is no system for which this now comes
into play, we can drop the questionable scandir code and thereby
alleviate any license worries?
That's the idea...
Albrecht
On 19.07.2011 15:29, Greg Ercolano wrote:
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds.
That's not a valid test[1]. You should comment out
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds.
Seems like we gotta fix this.
Bother.
Did it choke because we *need* the file, or just
On 07/19/11 08:14, MacArthur, Ian (SELEX GALILEO, UK) wrote:
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds.
Seems like we gotta fix this.
On 07/19/11 07:56, Albrecht Schlosser wrote:
On 19.07.2011 15:29, Greg Ercolano wrote:
I just tried a test on linux + osx where I removed the file
and ran a 'make clean; make'. The build stopped at that file
on both platforms, so it *is* getting linked on normal builds.
[..]
Made STR #2687 to track this issue.
http://fltk.org/str.php?L2687
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Hmm, can someone check the LGPL header src/scandir.c?
While doing the LGPL header mods for STR #2685,
I noticed this file appears to be part of the GNU C
Library, which may not be compat with the FLTK
static LGPL exception.
This code might need to be re-written.
13 matches
Mail list logo
