> On Jul 10, 2015 5:29 PM, "poma via Syslinux" <syslinux at
zytor.com> wrote:
>
> > The same as with the ISOLINUX, stable and git.
> > Only this time has nothing to do with the menu.
>
> 1) EXTLINUX is no longer a discrete variant. The installer extlinux now
> installs SYSLINUX.
> 2) William Kensington already saw a similar behavior wherein an ISOLINUX
> image failed before parsing the config.
> 3) It feels like this is a moving target where gcc keeps changing and
> different results get reported.
> 4) We'll likely need to make code akin to the old tracers (on screen or
> serial) to log progress.
>
> --Gene
There are at least 7 source files in Syslinux 6.03 including an
expression similar to:
>= ' '
and there would be many more files in the list if we were to modify or
relax the search criteria by just one character.
Among those files (just a sample of them), there are:
com32/elflink/ldlinux/cli.c
com32/cmenu/libmenu/tui.c
gnu-efi/gnu-efi-3.0/lib/console.c
memdisk/inflate.c
and:
com32/elflink/ldlinux/readconfig.c
com32/lib/sys/argv.c
com32/rosh/rosh.c
core/dmi.c
core/fs/pxe/urlparse.c
There are, of course, more. Not all of them might be relevant to this
gcc5 compatibility issue, but they might be candidates for review /
improvements (or, in other words, potential source of troubles related
to the matter in question).
If the Syslinux source code can be made more compatible with gcc v.5+,
I think it should, specially if there are no regressions introduced by
such potential changes.
Having said that, let's not forget that the range of inadequate
behaviors are triggered by using gcc v. 5+, and not seen in every
single hardware / firmware. This doesn't mean that gcc and/or the
firmware are the problem with certainty; just that those can be / are
the triggers (which is a positive thing, if we get to see code
improvements).
Just as Syslinux should try to "workaround" a buggy BIOS issue
whenever
possible, and it should also "work nicely" with gcc 5+ if possible (or
"as nicely as possible"), I think that gcc should also try to
"work
nicely" with others, and that users should check for firmware
("BIOS" /
"UEFI") updates and report their problems to relevant manufacturers.
Sure, most of that is not in our hands, but I hope we don't expect
"everything" from Syslinux (sometimes without even a clear feedback /
report, just with complains and demands). Users should report to the
hardware / firmware manufacturers, update their firmware versions, and
(IMHO) it would be beneficial if gcc's devs try to help with some tips
/ clues, or even some workaround parameter (considering that gcc 5+
seems to be triggering the issue whereas prior versions are not).
One thing that Syslinux could do is to improve debugging reports / logs
/ methods. As examples (not necessarily related to the current
troubleshooting issue only), output dots every X bytes during kernel's
load / hand over, and introducing a "standardized" way for c32 files
(plus "ldlinux.*") to include (although, not necessarily
"report") the
exact version (+ building date + commit + origin + debug_degree_flag
+...).
Finally, a small reminder. Since the issue is only present on specific
hardware / firmware, whatever might seem to "solve" the behavior in
one
system might not be really a solution for others. "This/that
works/fails for me" might be a useful report, rather than "this change
works for me so this is the solution that Syslinux must implement right
now for everyone". Let's be as helpful and as thorough as possible.
Regards,
Ady.
> _______________________________________________
> Syslinux mailing list
> Submissions to Syslinux at zytor.com
> Unsubscribe or set options at:
> http://www.zytor.com/mailman/listinfo/syslinux
>