similar to: [syslinux:master] Makefile: add lua.c32 to installables

From: Matt Fleming <matt.fleming at linux.intel.com> Move the MCONFIG files into a mk/ directory and give them more descriptive names. This is purely a cosmetic change to make the 'include' directives a bit more coherent by making it obvious exactly which MCONFIG file we're including. For example, in com32/lua/src/Makefile we exchange the line, include ../../MCONFIG for the

It has been observed that binaries contents are depending on the order of linked objects. This order is caused by GNU make's wildcard function and the position of sources on filesystem. This change tries to prevent this kind of randomness. Also consider building using -j1 flag to make it even more reproductible. Change-Id: Ie8eee7f336e6f1fa2863c4150d967afd15519f1d Bug:

From: Matt Fleming <matt.fleming at linux.intel.com> This series includes a patch (PATCH 1/6) that I sent previously but I thought it was worth sending it again since the rest of the series depends on it, and it also gives a bit of context. These cleanups make it simpler to do the big switchover to ELF modules on the elflink branch because the libraries in $LIBS are now contained in one

This is an attempt to avoid potential confusion. Here are some example sizes for the two Syslinux versions mentioned in the e-mail subject. Your build results might be different. 4.06: 1 55 Sep 22 22:23 modules/int18.com 1 108 Nov 1 18:07 version.mk 1 138 Nov 1 18:07 version.gen 1 138 Nov 1 18:07 version.h 1 239 Sep 22 22:23 modules/poweroff.com 1 408 Sep 22 22:25

Hi, I've tried to compile syslinux under mandriva, and the compilation always bails out because it hasn't created win32/syslinux.exe. As far as I understand, the build will work fine on a Windows / mingw installation, but not Linux. I've modified my Makefile to remove the win32/syslinux.exe from the build, and it now builds OK. This happened on 3.3.6 and also on 4.0pre.

So I realized I really need a better way to collect information from problematic machines, so I spent today rewriting the old memdump tool into a new "sysdump" tool. sysdump can write its output either to a serial port using ymodem[1] or over the network using TFTP *if* it was booted from the network, using PXELINUX. John R.: I would obviously like you to try this on the machine that

Op 2014-01-18 om 15:58 schreef Gene Cumm: > 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp > (perhaps in the wrong directory) while several Makefiles have an > include rule for *.tmp which I believe is causing some occasional > parallel build issues. > > make[3]: Entering directory `/home/gene/s/g/bios/memdump' > gcc_ok.6333.tmp:1: warning: NUL

On 01/18/2014 12:58 PM, Gene Cumm wrote: > 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp > (perhaps in the wrong directory) while several Makefiles have an > include rule for *.tmp which I believe is causing some occasional > parallel build issues. > > make[3]: Entering directory `/home/gene/s/g/bios/memdump' > gcc_ok.6333.tmp:1: warning: NUL

1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp (perhaps in the wrong directory) while several Makefiles have an include rule for *.tmp which I believe is causing some occasional parallel build issues. make[3]: Entering directory `/home/gene/s/g/bios/memdump' gcc_ok.6333.tmp:1: warning: NUL character seen; rest of line ignored gcc_ok.6333.tmp:1: *** missing separator.

On Sat, Jan 18, 2014 at 6:18 PM, H. Peter Anvin <hpa at zytor.com> wrote: > On 01/18/2014 12:58 PM, Gene Cumm wrote: >> 1) mk/syslinux.mk runs a shell to make a temp file gcc_ok.$$$$.tmp >> (perhaps in the wrong directory) while several Makefiles have an >> include rule for *.tmp which I believe is causing some occasional >> parallel build issues. >> >>

On Mon, Sep 14, 2015 at 05:50:58AM +0200, celelibi--- via Syslinux wrote: > index a705440..5ef6702 100644 > --- a/mk/efi.mk > +++ b/mk/efi.mk > @@ -10,6 +10,7 @@ core = $(topdir)/core > GCCOPT := $(call gcc_ok,-fno-stack-protector,) > EFIINC = $(objdir)/include/efi > LIBDIR = $(objdir)/lib > +EFIDIR = $(topdir)/gnu-efi/gnu-efi-3.0 Would it make sense to add AROPT =

From: Sylvain Gault <sylvain.gault at gmail.com> The error-prone shell scripts for building gnu-efi are replaced by a Makefile recipe. This is accompanied with a small update of gnu-efi which, despite not strongly mandatory, avoid recompiling gnu-efi and all the efi subtree on each invocation of make. Signed-off-by: Sylvain Gault <sylvain.gault at gmail.com> ---

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

Hello, This is a patch to allow building of the project using MSYS, MinGW, and MinGW-w64 with the following invocation: make -f Makefile.lite libFLAC libFLAC++ flac metaflac test_libs_common test_libFLAC test_libFLAC++ test_grabbag test_seeking test_streams utils examples This patch addresses eight points: 1. `uname -p` in MSYS returns "unknown" so we must use `gcc -dumpmachine`

make -r -C /mlsyslinux -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ OBJ=/mlsyslinux objdir=/mlsyslinux bios make[1]: Entering directory `/mlsyslinux' make -r -C /mlsyslinux/bios -f /mlsyslinux/Makefile SRC="/mlsyslinux" \ objdir=/mlsyslinux/bios OBJ=/mlsyslinux/bios HAVE_FIRMWARE=1 \ ARCH=i386 LDLINUX=ldlinux.c32 all make[2]:

Hi, Gene Cumm wrote: > > 3) It feels like this is a moving target where gcc keeps changing and > > different results get reported. Do we have indications that different versions of gcc5 cause different behavior on the same build and boot machines ? Ady wrote: > Since the issue is only present on specific > hardware / firmware, whatever might seem to "solve" the

From: Matt Fleming <matt.fleming at intel.com> The first two patches in this series are fixes for bugs reported by someone in #syslinux. The third makes dmitest.c32 actually wait for user input. If no one has any objections/concerns, I'll pull this into the official elflink branch. Matt Fleming (3): core: Print error message if we don't load ldlinux.c32 Clean up $(GPLLIB) leak

I'm having issues with the ifcpu[64].c32 modules. I am building a menu system (as opposed to the command line only options I was previously using) to make it easier for my boss to use PXE. I discovered the modules for auto detecting the CPU and thought hey, that's great! However, I'm having an issue where when I select to boot say System Rescue CD, it drops me to the command line

I've just pushed out a 6.00-pre1 release. This release includes support for booting EFI machines. The code is currently in the alpha stage. Having said that, you should expect most things to work correctly, including things like the graphical menu. Please help test if you can, and if you find any bugs, please report them. To facilitate building different versions of syslinux.efi (32-bit and

On Fri, 2012-06-29 at 07:42 -0700, syslinux-bot for H. Peter Anvin wrote: > elflink: fix dependency problem in cmenu/Makefile > > Instead of adding library dependencies implicitly, make them explicit > and use --as-needed to avoid bogus DT_NEEDED entries from being > generated. This is fine, but... > diff --git a/com32/cmenu/Makefile b/com32/cmenu/Makefile > index