similar to: [PATCH] remove _BSD_SOURCE definition

On Thu, Sep 18, 2014 at 12:34 AM, Chanho Park <chanho61.park at samsung.com> wrote: > The _BSD_SOURCE was deprecated since glibc-2.20. _DEFAULT_SOURCE can be > used instead of _BSD_SOURCE. However, there is no need to include > _BSD_SOURCE because the sources only have inline functions and calls > memcmp/cpy functions. Testing this myself on my build boxes, I see no issue. The

_BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc 2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should also be defined. [1]: https://sourceware.org/glibc/wiki/Release/2.20 Signed-off-by: Chanho Park <chanho61.park at samsung.com> --- dos/getsetsl.c | 2 ++ libinstaller/fs.c | 2 ++ libinstaller/syslxmod.c | 2 ++ 3 files changed, 6

The _BSD_SOURCE was deprecated since glibc-2.20. _DEFAULT_SOURCE can be used instead of _BSD_SOURCE. However, there is no need to include _BSD_SOURCE because the sources only have inline functions and calls memcmp/cpy functions. Signed-off-by: Chanho Park <chanho61.park at samsung.com> --- dos/getsetsl.c | 1 - libinstaller/fs.c | 1 - libinstaller/syslxmod.c | 1 - 3 files

Hi, > -----Original Message----- > From: Ferenc Wagner [mailto:wferi at niif.hu] > Sent: Thursday, September 25, 2014 4:42 PM > To: Chanho Park > Cc: syslinux at zytor.com > Subject: Re: [syslinux] [PATCH] define _DEFAULT_SOURCE for glibc-2.20 > > Chanho Park <chanho61.park at samsung.com> writes: > > > _BSD_SOURCE was deprecated in favour of

Chanho Park <chanho61.park at samsung.com> writes: > _BSD_SOURCE was deprecated in favour of _DEFAULT_SOURCE since glibc > 2.20[1]. To avoid build warning on glibc2.20, _DEFAULT_SOURCE should > also be defined. Why exactly is _BSD_SOURCE (or _DEFAULT_SOURCE) needed in the Syslinux sources? Maybe it would be worth pointing out in a comment. -- Thanks, Feri.

On Sun, Mar 6, 2016 at 8:21 PM, Shao Miller via Syslinux <syslinux at zytor.com> wrote: > On 3/6/2016 17:03, Pete Batard via Syslinux wrote: >> >> The problem was due to the following warning when compiling for 64-bit >> using using the latest WDK (7600.16385.1), with warning level 3 (/W3): >> >> 1>c:\rufus\src\syslinux\libinstaller\syslxmod.c(44) :

On Thu, Sep 25, 2014 at 3:51 AM, Chanho Park <chanho61.park at samsung.com> wrote: > Hi, > >> -----Original Message----- >> From: Ferenc Wagner [mailto:wferi at niif.hu] >> Sent: Thursday, September 25, 2014 4:42 PM >> To: Chanho Park >> Cc: syslinux at zytor.com >> Subject: Re: [syslinux] [PATCH] define _DEFAULT_SOURCE for glibc-2.20 >>

Hi Shao, You're right, "a=b=<immediate value>;" wasn't the actual issue. On 2016.03.06 20:34, Shao Miller via Syslinux wrote: > If this change is simply due to a mental note about an incident where a > compiler once complained about this type of thing The problem was due to the following warning when compiling for 64-bit using using the latest WDK (7600.16385.1),

More MSVC compatibility fixes, for packed structures. NB: In case you are aware of the issues that may come with MS vs GCC packing, so far, I have not seen evidence of detrimental impact from using ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for MinGW), with regards to the sections of code I am using in Rufus. -------------- next part --------------

On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > More MSVC compatibility fixes, for packed structures. > NB: In case you are aware of the issues that may come with MS vs GCC > packing, so far, I have not seen evidence of detrimental impact from using > ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for >

On 2016.03.07 03:27, Shao Miller via Syslinux wrote: > - Casting to a uintptr_t is ugly (and not C89, not that Syslinux cares > about that) Yeah, I'd have liked to avoid that too, but some compilers will complain about pointer arithmetic logic, unless you specifically use uintptr_t. But, considering your other very valid point, let me see if I can work something better here, that

This set of patches add some support for sector size >512. Currently it fixes extlinux, MBR for GPT and ext partitions. Other code is unaffected. This set of patches has been tested on a read Dell machine running a beta firmware.

Howdy. I'm one of the maintainers of Astlinux (www.astlinux.org). We're updating the kernel from 2.6.20, to 2.6.25 (.19), and as such, some packages that previously compiled stopped doing so. We also went from syslinux-3.63 to syslinux-3.72, hoping that a newer version would be more amenable to a more recent kernel. No joy. We're cross-compiling on FC8 (updated) on an i386

This is part of some patches to support sectors > 512. Currently I'm able to boot a Ubuntu kernel but seems that mboot is not working for some reason. This patch try to fix first stage of extlinux bootloader but have some problems with ADV Signed-off-by: Frediano Ziglio <frediano.ziglio at citrix.com> --- dos/syslinux.c | 2 +- extlinux/main.c | 36

Hi Shao, On 2016.02.24 23:43, Shao Miller via Syslinux wrote: > Did you happen to notice anything unusual when compiling with MinGW > under Linux, once 'ok' was removed? I seem to recall warnings about > unused results, but not of unused objects. Maybe that's an incorrect > recollection or maybe it's ancient history, however. I got no warnings with the patch on

This is the initial NTFS file system support for Syslinux :-) The following changes since commit 67954e370003d9bbfd8b58042669f2e9d532636f: ifmemdsk: remove spurious +x bit (2011-08-25 10:58:44 -0700) are available in the git repository at: git://github.com/pcacjr/syslinux.git ntfs-for-hpa Paulo Alcantara (34): Add NTFS filesystem support to Linux and Windows installers Initial

I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and while I could see that this #define was introduced in e4fc44 [1], but the reason to introduce it is not mentioned, and I can't really see a good reason to have it, especially as MSVC will happily compile that source. So far I have found no evidence that _GNU_SOURCE applies to memset/memmove/memcpy, which are the

From: Nicolas Cornu <ncornu at aldebaran.com> --- mtools/Makefile | 1 + mtools/syslinux.c | 59 +------------------------------------------------------ 2 files changed, 2 insertions(+), 58 deletions(-) diff --git a/mtools/Makefile b/mtools/Makefile index 0d0b1b2..c980420 100755 --- a/mtools/Makefile +++ b/mtools/Makefile @@ -9,6 +9,7 @@ SRCS = syslinux.c \

The variable 'ok' is never used and generates a warning. Remove it. Also ntfssect.c is designed to be compiled in non Unicode mode when using MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use of 'A' API calls) so that it doesn't break when compiled in Unicode mode, which is what Rufus uses with MSVC. -------------- next part --------------

Hello, Happy New Year! These patches make syslinux/linux support ext2/3/4, and it doesn't require the root privilege, I'd like to add a separate e2fs/syslinux, if that is more appropriate, it should be easy to do that. I put these patches on github so that you can easily get them in case you'd like to test them. (The repo's name is sys_tmp, which avoids confusing others, I will