Blir det skillnader mot vårt gamla bygge med devkit men utan din nya fix, eller mellan devkit med din fix och en icke-devkit där man inte använder sysroot? Dvs kan din fix göra så att devkit blir identiskt med utan devkit?
/Magnus > 4 feb. 2016 kl. 14:51 skrev Erik Joelsson <[email protected]>: > > Differences are extensive in most C++ object files. The problem with viewing > dissassembly diffs is that any difference tend to change all addresses later > in the file. > > /Erik > >> On 2016-02-04 13:43, Erik Joelsson wrote: >> I will investigate and report back. >> >> /Erik >> >>> On 2016-02-04 13:29, David Holmes wrote: >>>> On 4/02/2016 9:27 PM, Magnus Ihse Bursie wrote: >>>>> On 2016-02-03 14:33, Erik Joelsson wrote: >>>>> >>>>> >>>>>> On 2016-02-03 13:59, David Holmes wrote: >>>>>> Hi Erik, >>>>>> >>>>>>> On 3/02/2016 10:48 PM, Erik Joelsson wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this small fix for building on Solaris using a >>>>>>> devkit/sysroot. The Solaris Studio compiler does special inlining and >>>>>>> intrinsics with system calls, like memcpy. The problem is that it only >>>>>>> seems to do this if it finds the definition of the system call in a >>>>>>> header file in the /usr/include directory. See bug description and >>>>>>> comments for details. >>>>>>> >>>>>>> I have found a way to work around this. Internally, the compiler adds >>>>>>> the option -I-xbuiltin to mark the start of the system header includes >>>>>>> when calling a sub process. By adding this to our SYSROOT_CFLAGS, the >>>>>>> special inlining is re-enabled. >>>>>> >>>>>> We have no way of knowing whether that will mess with the compilers >>>>>> use of other header files. We seem to be on very thin ice here. We >>>>>> know it fixes this one problem, but we don't know what else it may do! >>>>> That is true. But then, we don't really know what else this compiler >>>>> is doing anyway, as is evident by your latest discovery. The way we >>>>> live with this is testing. We use the setup we have until it proves >>>>> not to work, we fix and we test. I'm just trying to do the best I can >>>>> with what we have. I would much prefer to ditch SS for gcc/clang >>>>> (where we seem to have way less problems) if it was my choice. I'm not >>>>> ready to give up the convenience of devkits/portable sysroots just >>>>> because one of the compilers we (have to) use needs a bit of special >>>>> handling to behave properly. >>>> >>>> I agree that this is a situation that's not really comfortable. :( But, >>>> as with many other things with the solaris studio compiler, in the end >>>> it's a result of the limited functionality of that compiler (in this >>>> case, the lack of a properly functioning --sysroot alternative). >>>> >>>> So in light of that, and Erik's comment about testing as the only way to >>>> be sure, I'd like to see Eriks fix get in. >>> >>> Do we have the means to do a binary comparison of the object files >>> before/after the change to ascertain what kind of affect this is having? >>> >>> Thanks, >>> David >>> >>>> /Magnus >>>> >>>> >>>>> >>>>> /Erik >
