similar to: [PATCH 1/3] lib: fix compilation warnings from MS's WDK

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

make[1]: Entering directory `/syslinux-4.02-6-ge841d69/dos' gcc -Wp,-MT,syslxopt.o,-MD,./.syslxopt.o.d -m32 -ffreestanding -fno-stack-protector -fwrapv -freg-struct-return -march=i386 -Os -fomit-frame-pointer -mregparm=3 -DREGPARM=3 -msoft-float -fno-exceptions -fno-asynchronous-unwind-tables -fno-strict-aliasing -falign-functions=0 -falign-jumps=0 -falign-labels=0 -falign-loops=0

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

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

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

I just tried to build syslinux-3.71-pre14-5-gfa6a60e and got the following: make[1]: Leaving directory `/syslinux/syslinux-3.71-pre14-5-gfa6a60e/dos' make[1]: find-mingw.sh: Command not found make[1]: Entering directory `/syslinux/syslinux-3.71-pre14-5-gfa6a60e/win32' gcc -Wp,-MT,syslinux.o,-MMD,.syslinux.o.d -W -Wall -Wno-sign-compare -Os -fomit-frame-pointer -D_FILE_OFFSET_BITS=64 -I.

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

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:

On 2016.03.06 13:13, Gene Cumm wrote: > Did Visual Studio actually complain about this one? WDK compiler (which I also use) if I recall correctly. At any rate, some older compilers do not like double initializations like this one, and I don't think this change should be much of a contention point, since it doesn't introduce any liability. Regards, /Pete

hello everybody, apologies if I'm missing something here Just tried to build 6.04-pre1 test version with: make bios installer and found some problems all (seemingly) related to inaccurate paths in various Makefiles. I enclose a complete patch at the end of this email, which details the problems I found and how they got fixed for me. As an example, this is the first error I got:

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

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) : warning C4242: > '=' : conversion from 'sector_t' to 'unsigned int', possible loss of data Then your

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 \

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

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

We support both device and directory as the target now. Signed-off-by: Robert Yang <liezhi.yang at windriver.com> --- libinstaller/syslxopt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libinstaller/syslxopt.c b/libinstaller/syslxopt.c index 3fc5519..d06719f 100644 --- a/libinstaller/syslxopt.c +++ b/libinstaller/syslxopt.c @@ -88,7 +88,7 @@ void __attribute__

Here is the patch for making syslinux enable opening partitions with fat filesystems (well, the architecture is in place to make it open other filesystems too). Usage is like this: #include <syslinux/io.h> #include <syslinux/partitions.h> #include <fs/fat/libfat.h> syslinux_devdesc dfd; struct libfat_filesystem* fs; diskinfo disk_info; char mbr[512]; static part_entry

In Syslinux 6.03 -> libinstaller/syslxopt.c: #n 50: const struct option long_options[] = { ... #n 60: {"raid-mode", 0, NULL, 'r'}, ... #n105: fprintf(stderr, ... #n112: " --raid -r Fall back to the next device on boot failure\n" Comparing line #60 vs. line #112:

I am trying to build an RPM starting from the TAR archive. The relevant error is: make[1]: Entering directory `/tmp1/Software/rpmbuild/BUILD/syslinux-5.00/libinstaller' perl bin2c.pl syslinux_bootsect < ../core/ldlinux.bss > bootsect_bin.c perl bin2c.pl syslinux_ldlinux 512 < ../core/ldlinux.sys > ldlinux_bin.c perl bin2c.pl syslinux_mbr < ../mbr/mbr.bin > mbr_bin.c perl

Ady <ady-sf at hotmail.com> writes: > In Syslinux 6.03 -> libinstaller/syslxopt.c: > > > #n 50: const struct option long_options[] = { > ... > #n 60: {"raid-mode", 0, NULL, 'r'}, > ... > #n105: fprintf(stderr, > ... > #n112: " --raid -r Fall back to the next device on boot failure\n" > > >