Mats wrote: > it's something we'll have to look into. Like I said, I don't quite remember > the > details - my memory hints that there were some non-LSB symbols emitted if you > go > the stack protector route, and they'd need to make an appearance in an LSB > version > to be usable, if so. It's not technically a complex issue if that's the case, > but logistically... will there be an LSB update that could do this?
OK. Is there anything I should do? Open a bug, or something? I'm a bit concerned by the question "will there be an LSB update that could do this?" Things seem to have been very quiet on LSB for a while: is the project in danger of shutting down? > The somewhat more complicated issue is that the stack canary code messes with > the > ABI, as it modifies the stack frame. I don't know that much about ABIs, but is this a problem? Presumably one can call stack-protected code from non-stack-protected code, and vice-versa? Does it affect the traceback system or other debugger functionality? > As to the technical question you raise above, I'm a little surprised at the > output, > the dumb code that tries to make decisions based on gcc version doesn't even > know > about gcc 5.x, and so avoids returning a value indicating it's a gcc 4 > compiler. > Of course it isn't a gcc 4, but that check should really be gcc-4-or-later. I thought it might be something like that. > Any gcc5 compiler used with lsbcc is "uncharted waters". OK. thanks, -- John Dallman ----------------- Siemens Industry Software Limited is a limited company registered in England and Wales. Registered number: 3476850. Registered office: Faraday House, Sir William Siemens Square, Frimley, Surrey, GU16 8QD. _______________________________________________ lsb-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lsb-discuss
