Re: wireshark 2.2.x build fail
On 10/16/16 18:56, Michael Butler wrote: On 10/16/16 11:36, Joe Marcus Clarke wrote: Seems like the easy fix would be to incorporate the fix for this bug, and then disable SSE4.2 in a CFLAGS override. The better fix would be to have clang do the same as GCC so that the test build would fail on those platforms that don't support SSE4.2. Personally, I feel that this whole approach is wrong. To have CONFIGURE set a flag asking for instructions not supported by the host for the whole project when only one module has a run-time check for them is depending on undefined behavior. This is plainly poor engineering. It so happens that GCC does the expected thing but there is no guarantee that any other compiler can or should. In CLANG's case, it found an opportunity to use an SSE-4.2 instruction in compiling LEMON and assumed it could use it as CONFIGURE told it explicitly that it could. "fixing" every compiler out there to be GCC-compatible is not an acceptable or desirable work-around. The option should only be set for the module prepared for and capable of handling the absence of the extended instructions, Sure. I think the better case is to do a runtime check of a binary built with this instruction set versus just a compiler check. Seems like the compiler check is what WS is settling on, though. Will any stub executable built with these instructions fail, or is there a specific call that needs to be made to test this? I imagine the latter. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gn...@freebsd.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: wireshark 2.2.x build fail
On 10/16/16 11:36, Joe Marcus Clarke wrote: Seems like the easy fix would be to incorporate the fix for this bug, and then disable SSE4.2 in a CFLAGS override. The better fix would be to have clang do the same as GCC so that the test build would fail on those platforms that don't support SSE4.2. Personally, I feel that this whole approach is wrong. To have CONFIGURE set a flag asking for instructions not supported by the host for the whole project when only one module has a run-time check for them is depending on undefined behavior. This is plainly poor engineering. It so happens that GCC does the expected thing but there is no guarantee that any other compiler can or should. In CLANG's case, it found an opportunity to use an SSE-4.2 instruction in compiling LEMON and assumed it could use it as CONFIGURE told it explicitly that it could. "fixing" every compiler out there to be GCC-compatible is not an acceptable or desirable work-around. The option should only be set for the module prepared for and capable of handling the absence of the extended instructions, Michael ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: wireshark 2.2.x build fail
On 10/15/16 21:06, Michael Butler wrote: Just a "heads up": wireshark 2.2.x introduces the compiler flag "-msse4.2" via 'configure' if the compiler accepts that flag. The capability, or otherwise, of the host machine is ignored as it is expected that the one module in which GCC will use these instructions has a run-time check. This does not work for CLANG on "deficient" hardware; LEMON (part of the build tool-chain) will also be compiled with these extended instructions and cause exceptions on hardware that doesn't support them :-( There's a related discussion on the wireshark-bugs list referring to "bug 10792" Seems like the easy fix would be to incorporate the fix for this bug, and then disable SSE4.2 in a CFLAGS override. The better fix would be to have clang do the same as GCC so that the test build would fail on those platforms that don't support SSE4.2. Joe Michael -- Joe Marcus Clarke FreeBSD GNOME Team :: gn...@freebsd.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
