Activity for Eli Schwartz
-
Eli Schwartz created ticket #29
Compilation fails when autotools is not installed.
-
Building flightgear with LTO fails due to ODR violation
-
I can't try current trunk as it doesn't build since [r14858]. Regenerating the autotools now breaks once it hits that directory. No time to investigate tonight.
-
I'm agreeing that the change from a couple months ago is a good fix, because I backported it to: https://downloads.sourceforge.net/xsb/XSB-4-0-0.tar.gz (with additional patches from https://dev.gentoo.org/~keri/distfiles/xsb/xsb-4.0.0-gentoo-patchset-3.tar.gz) I haven't tried building from git, no.
-
I'm agreeing that the change from a couple months ago is a good fix, because I backported it to: https://downloads.sourceforge.net/xsb/XSB-4-0-0.tar.gz (with additional patches from https://dev.gentoo.org/~keri/distfiles/xsb/xsb-4.0.0-gentoo-patchset-3.tar.gz) I haven't tried building from git, no.
-
Unfortunately after backporting the patches, it still fails: -e [x86_64-pc-linux-gnu-gcc] loader_xsb.c using -fPIC -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types -Wno-error=format-security loader_xsb.c: In function ‘get_index_tab’: loader_xsb.c:136:16:...
-
Oh hrm right, fixed by edce993d1a837707781dbd4b5025e22e694c9053.
-
Note that implicit-function-declaration is tied to https://sourceforge.net/p/xsb/bugs/265/ This is an easy case because you can just include the header you forgot. Some Modern C errors are a lot harder to fix.
-
I see you committed a fix, unfortunately attempting to backport it emits a different fatal error instead: In file included from tst_utils.c:45: cell_xsb_i.h: In function ‘bld_boxedfloat’: cell_xsb_i.h:42:5: error: implicit declaration of function ‘memcpy’ [-Werror=implicit-function-declaration] 42 | memcpy(&tempUIFloat,&value,sizeof(tempUIFloat)); | ^~~~~~ cell_xsb_i.h:1:1: note: include ‘<string.h>’ or provide a declaration of ‘memcpy’ +++ |+#include <string.h> 1 | #include "register.h" cell_xsb_i.h:42:5:...
-
It should, yes, that's the local fix I made too.
-
tests: fix compilation with modern compilers
-
Slightly more worrisome: /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../include -I./../include -I../include -DXBAE_PER_CELL -march=native -fstack-protector-all -O2 -pipe -fdiagnostics-color=always -frecord-gcc-switches -flto=4 -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing -Wformat -Werror=format-security -Werror=implicit-function-declaration -Werror=implicit-int -Werror=int-conversion -Werror=incompatible-pointer-types -Wall -c -o Methods.lo...
-
Build fails with LTO
-
Build fails with LTO
-
Building sdcc with LTO fails due to ODR violations
-
Build fails with strict-aliasing violations.
-
Build fails with LTO
-
Well my problem was that it was asking for an m4 file that doesn't exist. I didn't expect the original patch to update configure -- just that the project maintainers should be ensuring they dont get out of sync.
-
The patch modifies configure.ac, but configure is not regenerated and really should be. (It currently does fail with an autoconf error: /usr/bin/m4:aclocal.m4:6178: cannot openacinclude.m4': No such file or directory`.)
-
Also while testing this with make -k I got a highly confusing error because somehow make succeeded instead of failing??? Even though a rule failed to compile. As a result my build script continued on to the install phase and compiled the failing program without any CFLAGS or LDFLAGS, which "worked" but should not have. It would be ideal if CFLAGS / LDFLAGS defined when the build is configured would persist across invocations... GNU autotools or meson would both do so. (imake is deprecated; xorg uses...
-
Build fails with LTO
-
The standards conformant way to do this without invoking UB is to use either that (union type access) or a memcpy. Both are commonly used in this scenario. Both will produce, on gcc or clang with optimizations enabled, the same code (in fact, the same code that the strict-aliasing violation produces, except the aliasing could trigger UB and explode instead). It's a well known pattern that the compiler has been taught to recognize. The memcpy guarantees there are no alignment issues whereas the union...
-
P.S. Is there any timeline for getting the code rewritten? Using CFLAGS="-Werror=strict-aliasing" finds a bunch of issues, and could be incrementally fixed.
-
Important compiler safety options are only used if CFLAGS isn't set
-
Build fails with implicit-int in a configure test probe
-
Build fails with strict-aliasing violations.
1