Gene Cumm
2014-Dec-22 11:11 UTC
[syslinux] [PATCH] check-gnu-efi.sh: print the output of build-gnu-efi.sh
On Nov 25, 2014 12:30 AM, "Anatol Pomozov" <anatol.pomozov at gmail.com> wrote:> While we discuss gnu-efi. How difficult to make it using system-wide > installed library instead of checking out and building it? Some > systems already have gnu-efi packaged/installed. It makes sense to use > it.The first attempt was to do exactly that however Syslinux depended on too many bleeding edge commits of gnu-efi to make it viable. It also levels the field such that everyone has the same version. The only viable alternatives I can think of are: 1) Use our own repo. 2) Put a Makefile variable in to indicate to use system then check if sufficient else fail the entire build. Bear in mind this also complicates debugging. --Gene
Ady
2014-Dec-22 16:29 UTC
[syslinux] check-gnu-efi.sh: print the output of build-gnu-efi.sh
> Syslinux depended on too many bleeding edge commits of gnu-efi to > make it viable.That _seems_ to be no longer accurate. The official 6.03 release (2014Oct06) was built based on the gnu-efi commit: ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999 from 2014Feb13. At the time Syslinux 6.03 was released, the build was no longer using a "bleeding edge" commit of gnu-efi (it was several months old and dozens of commits old). By the time I am writing this email, the Syslinux source code is still pointing to the same "old" commit and there are more than 50 newer ones in gnu-efi. Although at some point there were reports (maybe it was just one, or two) that building with a specific newer commit of gnu-efi would fail, I believe that there should be a new attempt to build Syslinux with a newer gnu-efi commit / version, as to at least try to reduce the reported problems about syslinux.efi failing in certain VM environments (OVMF, KVM, whatever). I'm not saying it has to be now, but it might be worth testing this matter before the next pre-release (whenever it might occur). In particular, the *gnu-efi.sh scripts in Syslinux should be tested with the new gnu-efi git tree (changed, 2014Nov25).> It also levels the field such that everyone has the same version.Using a consistent version / commit of gnu-efi makes sense. Otherwise, the resulting behavior could be changing (or the build might fail for some reason), according to whichever version / commit is "freely" used. As I said above, it might be worth pointing the gnu-efi submodule to a newer "consistent" commit (or version) and resolve any potential issues with it before the next Syslinux pre-release. Regards, Ady.
Patrick Masotta
2014-Dec-22 17:11 UTC
[syslinux] check-gnu-efi.sh: print the output of build-gnu-efi.sh
I really think we should not take chances; Syslinux source should include (probably as an optional download tarball) the gnu-efi used to build the particular Syslinux version. Pat -------------------------------------------- On Mon, 12/22/14, Ady <ady-sf at hotmail.com> wrote: Subject: Re: [syslinux] check-gnu-efi.sh: print the output of build-gnu-efi.sh To: syslinux at zytor.com Date: Monday, December 22, 2014, 9:29 AM > Syslinux depended on too many bleeding edge commits of gnu-efi to > make it viable. That _seems_ to be no longer accurate. The official 6.03 release (2014Oct06) was built based on the gnu-efi commit: ab54e2b40e914d0ca01dc3d44c8d4eb8517bf999 from 2014Feb13. At the time Syslinux 6.03 was released, the build was no longer using a "bleeding edge" commit of gnu-efi (it was several months old and dozens of commits old). By the time I am writing this email, the Syslinux source code is still pointing to the same "old" commit and there are more than 50 newer ones in gnu-efi. Although at some point there were reports (maybe it was just one, or two) that building with a specific newer commit of gnu-efi would fail, I believe that there should be a new attempt to build Syslinux with a newer gnu-efi commit / version, as to at least try to reduce the reported problems about syslinux.efi failing in certain VM environments (OVMF, KVM, whatever). I'm not saying it has to be now, but it might be worth testing this matter before the next pre-release (whenever it might occur). In particular, the *gnu-efi.sh scripts in Syslinux should be tested with the new gnu-efi git tree (changed, 2014Nov25). > It also levels the field such that everyone has the same version. Using a consistent version / commit of gnu-efi makes sense. Otherwise, the resulting behavior could be changing (or the build might fail for some reason), according to whichever version / commit is "freely" used. As I said above, it might be worth pointing the gnu-efi submodule to a newer "consistent" commit (or version) and resolve any potential issues with it before the next Syslinux pre-release.? Regards, Ady. _______________________________________________ Syslinux mailing list Submissions to Syslinux at zytor.com Unsubscribe or set options at: http://www.zytor.com/mailman/listinfo/syslinux
Anatol Pomozov
2014-Dec-22 21:30 UTC
[syslinux] check-gnu-efi.sh: print the output of build-gnu-efi.sh
Hi On Mon, Dec 22, 2014 at 8:29 AM, Ady <ady-sf at hotmail.com> wrote:> Using a consistent version / commit of gnu-efi makes sense. Otherwise, > the resulting behavior could be changing (or the build might fail for > some reason), according to whichever version / commit is "freely" used.As an active package maintainer I strongly believe in idea that software should use system packages as much as possible. The reasons are: - embedding libraries makes project bloating and the build system more complicated. - package maintainers tend to provide higher quality support for packages than alone developers. System libraries get bug/security fixes, version updates faster than libraries embedded into projects. And embedded libraries are usually left at some obsolete version just because developer have no time to update it. - compiling a project with already-built system libraries is faster than compile embedded libraries each time. I am not an syslinux/efi expert but for me it looks like syslinux can be perfectly fine using system gnu-efi library. For example in Linux Arch both refind and gummiboot use the system library and never had problems with it.
Possibly Parallel Threads
- [PATCH] check-gnu-efi.sh: print the output of build-gnu-efi.sh
- check-gnu-efi.sh: print the output of build-gnu-efi.sh
- check-gnu-efi.sh: print the output of build-gnu-efi.sh
- [PATCH] check-gnu-efi.sh: print the output of build-gnu-efi.sh
- gnu-efi submodule WAS: efi: Makefile improvement