similar to: Makefiles: includes and rule prerequisites

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. >> >>

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

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

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

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

Hello, I poked a little bit to extract the list of modules dependencies in Syslinux v6 (see below). I have attached a bash script that generate a nice table from the tarball. The output can either be an ASCII table, or wiki markup, typically for the page Library_modules[1]. I am not in the wiki Editor group, so I can't put that in the wiki. anyway, here's an updated dependency tree for

From: Matt Fleming <matt.fleming at intel.com> The following patch series is available at, git://git.zytor.com/users/mfleming/syslinux.git elflink All patches are against the 'elflink' branch. This series fixes a few serious bugs and some behavioural incompatibilities with the 4.x series. Matt Fleming (19): ldlinux: Initialise 'p' before using it. ldlinux: Parse

I think the Syslinux 5.00 branch is now at the point where I believe it it is feature complete and should be able to replace the main Syslinux branch. As such, it is important that we get wider testing, and especially that people let us know if and where it breaks. As of right now, there aren't any known bugs...

I'm seeing some sporadic build failures with 'make -j4'. The failures are: make[4]: *** No rule to make target 'hello.c32', needed by 'all'. Stop. I've only seen the failures with com32/samples/hello.c32 and com32/rosh/rosh.c32. I'm not a make expert, but I think it's due to missing dependencies. This patch seems to fix my failures, but I'm

From: Matt Fleming <matt.fleming at linux.intel.com> This series fixes some bugs and switches the elflink branch to be entirely ELF modules. It applies on top of, http://syslinux.zytor.com/archives/2011-April/016369.html The deletions in the diff stat below are mainly from deleting com32/elflink/modules (finally!). Now there should be no duplicate code because we don't need COM32 and

Hi there, ----- Original Message ----- From: koxudaxi at gmail.com To: syslinux at zytor.com Date: 01.04.2013 10:00:27 Subject: Re: [syslinux] Problem with pxelinux 5.0 and memtest > On 04/01/2013 09:28 AM, H. Peter Anvin wrote: >> On 03/31/2013 05:26 PM, Koudai Aono wrote: >>> I ran the test on a x86 emulator is called Oracle VirtualBox. >>> I think it might not be

I have, hopefully, found and fixed the issue with non-kernel binaries that appeared in 3.35. As a result, I have pushed out 3.36-pre6 and am classifying it as a release candidate. Please try it out, especially if you have had problems with 3.35. ftp://ftp.kernel.org/pub/linux/utils/boot/syslinux/Testing/ -hpa

This just came up on IRC, 15:01 < chithead> the first one that fails is ld -m elf_i386 -Wl,-O1 -Wl,--as-needed -Bsymbolic -pie -E --hash-style=gnu -T /var/tmp/portage/sys-boot/syslinux-6.01_pre5/work/syslinux-6.01-pre5/core/i386/syslinux.ld -M -o ldlinux.elf ldlinux.o \ 15:01 < chithead> --start-group libcom32.a --whole-archive

Hi, I have been using 6.03-pre11 lpxelinux.0 to deliver standard (TFTP) and HTTP based vmlinuz and kernel images. Things are working fine. When I upgraded the same to 6.03-pre12 it stopped working. On the console of the machine that is booting, is stalls infinitely at the line: PXELINUX 6.03 lwIP 6.03-pre12 Copyright (C) 1994-2014 H. Peter Anvin et al Screen shot attached. FWIW: 1. the

Hello syslinux maintainers, I came across the issue of syslinux crashing with some EFIs in the UEFI boot mode. Upon closer investigation it turned out that most object files which go into syslinux efi64 are compiled with the so-called red zone. Some EFIs follow Windows ABI more strictly and cause syslinux to crash due to stack overwrite. Looking at mk/efi.mk there was a previous attempt to fix

On Thu, Nov 15, 2018 at 1:10 PM Ady Ady via Syslinux <syslinux at zytor.com> wrote: > > Here are some comments and questions for you. > Thanks. I've have my scripts to a better state, including installing/using qemu to uefi and legacy boot the usb stick for testing. It mostly works for me, but the "wget a tarball of binaries" step isn't going to sit well with

> > In message <BLU0-SMTP2805E16A0E7A33B925EDF458BB80 at phx.gbl>, > Ady <ady-sf at hotmail.com> wrote: > > >Now, to move forward with Clonezilla in your USB drive, we need to > >proceed with some steps that are not as simple as dd'ing an image. > > Apologies for my impertinence, but I have one question: Why? > > I was under the impression

I want to eufi boot this image: http://cdn-fastly.deb.debian.org/debian/dists/testing/main/installer-amd64/current/images/hd-media/boot.img.gz there is a bug against it: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913523 I'd like to fix the resulting usb stick for my use, and also fix it in a way that can be used to fix the upstream bug. I'm trying to follow the guids

Well, I decided to get ROSH back out and try to get it functioning in Syslinux-4. As has been my habit, I first recompiled the Linux binary and tried it out. In the beginning of ROSH, it calls console_ansi_std(). When I was working on this in the past, using this function ensured both the Linux and the Syslinux/COM32 binaries function similarly. When using fgets() to get an input string in the