similar to: Heads up on syslinux breakage in Ubuntu

On 07/11/15 19:38, Ady via Syslinux wrote: > >> >> Just a heads up that syslinux is broken in the current Ubuntu, syslinux >> just shows "Boot error". Downgrading to syslinux from 15.04 works perfectly. >> >> Ubuntu bug is here: >> https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1499746 >> >> This is mostly in case anyone

2015-11-07 23:00 UTC+01:00, Tim Fletcher via Syslinux <syslinux at zytor.com>: > On 07/11/15 19:38, Ady via Syslinux wrote: >> >>> >>> Just a heads up that syslinux is broken in the current Ubuntu, syslinux >>> just shows "Boot error". Downgrading to syslinux from 15.04 works >>> perfectly. >>> >>> Ubuntu bug is here:

On Sun, Nov 08, 2015 at 01:34:26AM +0100, Celelibi via Syslinux wrote: > 2015-11-07 23:00 UTC+01:00, Tim Fletcher via Syslinux <syslinux at zytor.com>: > > On 07/11/15 19:38, Ady via Syslinux wrote: > >> > >>> > >>> Just a heads up that syslinux is broken in the current Ubuntu, syslinux > >>> just shows "Boot error". Downgrading

> > Just a heads up that syslinux is broken in the current Ubuntu, syslinux > just shows "Boot error". Downgrading to syslinux from 15.04 works perfectly. > > Ubuntu bug is here: > https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1499746 > > This is mostly in case anyone shows up on the mailing list with a > mystery broken syslinux from latest

On 03/08/2016 02:53 PM, Gene Cumm wrote: > > Poma, in my opinion, this behavior means it's your/Fedora's responsibility > to propose a change that distinguishes between broken and working NASM > 2.11.06 or revert the commit in your/Fedora's build. > Yes, it is highly problematic to have especially build tools with version numbers that don't match upstream having

Using a boot prompt without a menu makes Syslinux 6.03-6 booting the default label only, ignoring the label that was entered. Auto completion of the defined labels works, though. Can anyone confirm this? Further, removing the DEFAULT <label> definition makes Syslinux panic, ignoring any boot label or command entered. Instead, without a default, I'd expect it to wait for user input,

On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > Just want to remind everyone that we plan to stop using mach_override in > asanin favor of OSX's native function interposition. > So, we probably don't want to spend too much effort fixing mach_override. > > --kcc Kostya, Unless I am misunderstanding the code in asan/asan_intercepted_functions.h,

+kremenek, ganna On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > Just want to remind everyone that we plan to stop using mach_override in > > asanin favor of OSX's native function interposition. > > So, we probably don't want to spend too much effort fixing

On Sat, May 07, 2016 at 09:56:59PM +0300, Ady via Syslinux wrote: > On Sun, May 01, 2016 at 11:58:41AM +0200, Alexander Freudenberg via Syslinux wrote: > > Using a boot prompt without a menu makes Syslinux 6.03-6 booting the > > default label only, ignoring the label that was entered. Auto completion > > of the defined labels works, though. Can anyone confirm this? > >

Just want to remind everyone that we plan to stop using mach_override in asanin favor of OSX's native function interposition. So, we probably don't want to spend too much effort fixing mach_override. --kcc On Fri, Nov 30, 2012 at 4:46 AM, Alexander Potapenko <glider at google.com>wrote: > Looks like this happens on x86_64 because the position of __cxa_throw > is too far from

On Sat, Dec 01, 2012 at 05:42:15PM +0400, Kostya Serebryany wrote: > +kremenek, ganna > > On Sat, Dec 1, 2012 at 4:33 AM, Jack Howarth <howarth at bromo.med.uc.edu>wrote: > > > On Fri, Nov 30, 2012 at 01:41:05PM +0400, Kostya Serebryany wrote: > > > Just want to remind everyone that we plan to stop using mach_override in > > > asanin favor of OSX's

Currently the replacement of allocation routines is based on creating a new malloc zone and a new CFAllocator (because the allocator replacement is done later than it could be, we must have both). This makes us depend on CoreFoundation to call CFAllocatorSetDefault. Because of some bugs in CF which start firing after CFAllocatorSetDefault, we have to add several hacks to circumvent the effects of

On Tue, Dec 04, 2012 at 10:36:18AM -0800, Alexander Potapenko wrote: > Currently the replacement of allocation routines is based on creating > a new malloc zone and a new CFAllocator (because the allocator > replacement is done later than it could be, we must have both). This > makes us depend on CoreFoundation to call CFAllocatorSetDefault. > Because of some bugs in CF which start

I applied the patch Gene wrote here: https://github.com/triton/nixpkgs/commit/06e146b2ce5eaaa54ebea061dd5797f89ae2c37c The tree after that commit is entirely based on gcc5. In order to do a test with gcc4.9, I reverted: https://github.com/triton/nixpkgs/commit/8ccc1f121f379f4d66ce0a66f581c49d25fb4e15#diff-d7222640d82ff920625e9311d05a0137 and then built two images, one entirely based on gcc4.9

Looks like this happens on x86_64 because the position of __cxa_throw is too far from the allocated branch island (should be <2G). This can be solved by allocating the branch islands somewhere near the text segment (look for kIslandEnd in asan_mac.cc, this is currently 0x7fffffdf0000) or by patching the function with a longer instruction sequence that stores the jump target in a register and

> > As opposed to "label", > "dlabel" ... > https://github.com/ErwanAliasr1/syslinux/commit/ebf8cbf > > SeaBIOS / GRUB2 > > ... > ... > <target dev='vdc' bus='virtio'/> > <boot order='3'/> > ... > ... > <target dev='vdd' bus='virtio'/>

Hello testers, RC4 has just been tagged (at r229782 on the branch). RC3 was disqualified due to an infloop that Duncan reported, and fixed in r229421. That, fixes for a few scary X86 bugs, a GCC5 bootstrap problem (PR22625), and parts of PR22589 is included in RC4. Baring any showstoppers, this release candidate will be promoted to release. Please let me know how it looks and upload binaries

I tried compiling using GCC. First, I changed config.site to: ~/R-3.2.2$ svn diff config.site Index: config.site =================================================================== --- config.site (revision 69236) +++ config.site (working copy) @@ -278,3 +278,8 @@ ## Path to the version of pkg-config to be used for locating cairographics. ## PKGCONF = +F77=gfortran48 +FC=${F77} +CC=gcc48

No. The gcc cross compiler being used (tilera-gcc) is indeed 64-bit. Thanks On Tue, Oct 28, 2014 at 11:01 AM, Anton Korobeynikov < anton at korobeynikov.info> wrote: > Looks like your gcc is 32-bit and you're trying to load 64-bit plugin. > > On Tue, Oct 28, 2014 at 8:27 PM, Ajay Panyala <ajay.panyala at gmail.com> > wrote: > > Hi Brian, > > > >

> I also sent (off-list) a bootable floppy image to GeneC, using binaries > from Fedora 24, package version "6.03-6" (coincidentally), and a simple > syslinux.cfg, replicating the behavior. > Testing with: _ 6.03-8.fc24 : still the same unwanted behavior as 6.03-6.fc24; _ 6.04-0.1.fc25: works correctly (regarding this matter). I still think that distributions using