similar to: linking external library into module

Thank you for the confirmation about the ABI issue. I'm a bit puzzled by your answer for my #2, below. I could easily be missing something, but I was under the impression that what I had changed was the position of the command line flags to ld, not the relative position and ordering of the linked libraries. Am I misunderstanding what is stored in $(LDFLAGS)? I mean, I'm not ending up

Thank you, that clears everything up. > -------- Original Message -------- > Subject: RE: [syslinux] linking external library into module > From: "H. Peter Anvin" <hpa at zytor.com> > Date: Thu, September 29, 2016 2:55 pm > To: jeff.williams at pideso.com, syslinux at zytor.com > > > On September 29, 2016 7:16:19 AM PDT, jeff.williams at pideso.com wrote:

I'm hoping this tickles some dendrites as both google and the various documentation doesn't seem to provide any insight. I'm writing a com32 module for use on a x86-32 machine with a BIOS (not EFI). The code that I write into the module executes correctly. However, I also have a static library that has several routines that I want to use. The static library doesn't rely on any

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

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

This patch builds a floppy image with contains HDT, so users of GRUB or GRUB4DOS can use HDT too, without installing Syslinux. When you compile Syslinux, this floppy image isn't build automatically. To build it, runthe following from the extracted Syslinux source: $ cd ./com32/hdt $ make hdt.img As suggested by Pierre-Alexandre Meyer, all extra files required for building the floppy

Hi, This series targets automatic boot menu generation, but most of it is the Lua upgrade, because I got tired reading deprecated API docs. It's mostly a straightforward forward port of the earlier Syslinux specific changes to Lua 5.1, except that: * I chose the add a stub getenv() implementation to the COM32 API instead of #ifdefing out all the references in Lua, and * I kept oslib

[resending, cutting out git pull-request output to make message smaller] Hi all, I have written a COM32 module called "acpioff", that, not surprisingly, powers off a machine using ACPI. I have tested it only using pxelinux.0 with a SeaBIOS/Qemu virtual machine. Since the changeset pulls in a "Linux-ized" version of the open source ACPI Component Architecture, it was too big

1) code split and move Iterator related functionality is yanked from chain.c and moved to iterator.{c,h}. Both are moved to com32/chain and this way chain.c is ready for further splitting. Alternatively, partiter could be moved to com32/lib at any time in the future. It's potentially useful for other modules (e.g. if someone wanted to code partition dumper or editor). 2) Iterator updates

It seems that the com32 module is a raw binary file without any control infomation. To factor it into suitable for dynamic linking, we need add some control sections, but can we still tell that file a com32 file ? why we use the elf file format directly? Thank you -- Ziyu Yu

At boot: prompt, COM32 module calls with full path fails silently. Please let me know if this is not the best fix for it. Also, please forgive me if this is not a bug and I did something wrong on my end. The following changes since commit 2779b713bdd8644ee2b52962ece6daa209b4ba6b: com32: remove duplicate modules (2012-05-22 20:59:51 -0300) are available in the git repository at:

Hi Peter, Please pull the following changes. Paulo, I had to revert your "pxe: resolve names via DNS from protected-mode code" change because dns_resolv() is only implemented for PXELINUX and causes undefined symbol references for ISOLINUX, etc. Feel free to make the change again on top of the revert. The following changes since commit e7bd19def830e8341b1a100956345f1028740b9e:

I need to do PCIe memory mapped configuration space access from a com32 module. (ECAM, memory mapped, not CAM, which uses I/O port access). I know how to find the base address to the config space in Linux and use ECAM to access configuration registers. com32/lib/pci does not use ECAM. In Linux the region for ECAM is referred to as PCI MMCONFIG. (often shows up as e0000000-efffffff, see

The program name of the module can't be retrieved with argv[0]. I tested it by running cat.c32 (com32/samples/cat.c32). In Syslinux 3.85, argv[0] returns an empty string. In Syslinux 4.00-pre36, argv[0] returns some garbage characters. ISOLINUX 3.85 2010-02-20 ETCD Copyright (C) 1994-2010 H. Peter Anvin et al argv = 0x00182c44 argv[0] = 0x07fbffc3 = "" argv[1] = 0x00182c34 =

Alex Bligh <alex at alex.org.uk> writes: > Firstly, this line: > > syslinux.run_kernel_image("mboot.c32", bootstr, 0, 0) > > no longer works at all as is. I think it was broken (probably > intentionally) by this commit: > > commit 4bbaf68cbf6c9a4c850f71b19bfb9604b9327efb > Author: Ferenc W?gner <wferi at niif.hu> > Date: Sun Oct 13 22:30:16

With not too much effort I've made Doug Lea's malloc work in the com32 environment. I've also hacked up some start up code to create the argv array so it's possible to start with main. Should I post it here or what? -- Jupiter 2004-02-20 21:17:51.911 UTC (JD 2453056.387406) X = -5.172371620, Y = 1.409543883, Z = 0.730102025 X' = -0.002302696, Y' =

This module is able to power off a system via APM. It replaces the poweroff COMBOOT module. Signed-off-by: Sebastian Herbszt <herbszt at gmx.de> --- com32/modules/Makefile | 2 +- com32/modules/poweroff.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 89 insertions(+), 1 deletions(-) create mode 100644 com32/modules/poweroff.c diff --git