Activity for martin.vaeth
-
martin.vaeth posted a comment on ticket #5
BTW, "gcc -E -" and "clang -E -" works within pipes (i.e. if "-" is used as the file name). (Also GNU's cpp and clang-cpp accept the - argument). I suppose that "gcc -E -" or "clang -E -" are preferrable over "cpp" or "clang-cpp", because at least cpp produces output which avoids some GNU features, see https://stackoverflow.com/questions/43967458/difference-between-cpp-and-gcc-e
-
This was a tough one: It turned out that the CPPX I passed contained an embedded newline. This in turn caused an sed error, leading to a non-generation of rules.cnf, and so half of the build system went havoc. Suprisingly that the missing -lcaps options (and actually also missing -ldl options) were the only visible effect. Summarizing: All is fine now except for the missing patch to strlcat (and the not satisfactory heuristics for the CPPX default).
-
This was a tough one: It turned out that the CPPX I passed contained an embedded newline. This is turn caused an sed error, leading to a non-generation of rules.cnf, and so half of the build system went havoc. Suprisingly that the missing -lcaps options (and actually also missing -ldl options) were the only visible effect. Summarizing: All is fine now except for the missing patch to strlcat (and the not satisfactory heuristics for the CPPX default).
-
The related functions have been moved to libc The NEWS in the glibc-2.26 tarball did not contain such an information. (Which I would have expected since the latest version of libcap appears to be 2.25.) Also Debian seems to have a separate package for libcap: https://packages.debian.org/stretch/libcap-dev Apparently, the package with the binary library is called libcap2 in Debian. Also on kernel.org, the library seems to be called libcap2 (although it installs libcap.so.2): https://mirrors.edge....
-
Is there a way to get the recent changes you mentioned before the release? I have no linux installation that still has libcap I do not know about the relation of these libraries; they have similar version numbers, but glibc depends on libcap if USE=caps is specified. The error message was this OBJ/amd64-linux-cc/pic/remote.:remote.c:function rmtgetconn: error: undefined reference to 'cap_get_proc' OBJ/amd64-linux-cc/pic/remote.:remote.c:function rmtgetconn: error: undefined reference to 'cap_get_flag'...
-
so there IS a broken compiler installation Is there a standard with the requirement that certain binaries belong to the same entry of PATH? I would actually expect that it is not so rare that a particular binary is overridden by an earlier /usr/local/bin entry. Perhaps simply "cpp" (or first ${CC%gcc}cpp) could be used as a fallback if it is executable via PATH. Anyway, for my purpose I consider the problem as solved. mean that I recently added it to the linker map file I see. Thanks. So I will wait...
-
I was actually wrong. (I had instructed gentoo's toolchain functions to export CPP, and observed that they export "gcc -E". But this was not the problem). The actual problem is that your method of test conflicts with gentoo's ccache wrapper: This is a directory /usr/lib/ccache/bin which preceeds /usr/bin in PATH and which for every compiler executable supported by ccache contains a corresponding symlink to /usr/bin/ccache (which in turn will call the corresponding executable if it cannot find the...
-
Thanks. There does exist cpp and alsox86_64-pc-linux-gnu-cpp in the same directory, but gentoo's default environment exports some environment variables in which gcc -E is preferred. After exporting an appropriate CPP, compilation seems to proceed further, but I get another linking problem: + x86_64-pc-linux-gnu-gcc -o OBJ/amd64-linux-cc/mkisofs OBJ/amd64-linux-cc/mkisofs.o OBJ/amd64-linux-cc/tree.o OBJ/amd64-linux-cc/write.o OBJ/amd64-linux-cc/hash.o OBJ/amd64-linux-cc/rock.o OBJ/amd64-linux-cc/...
-
The output of the above compiler command is empty (i.e. even if I remove all the rest of the pipe).
-
For testing, I edited lines 65/66 in RULES/rules.shl so that the command is not hidden. The relevant output from the make run is ...echo " ==> LOCALIZING mapfile \"OBJ/amd64-linux-cc/pic/libschily-mapvers\""; ==> LOCALIZING mapfile "OBJ/amd64-linux-cc/pic/libschily-mapvers" ...x86_64-pc-linux-gnu-gcc -E -DSCHILY_BUILD -IOBJ/amd64-linux-cc/pic -I../incs/amd64-linux-cc -I../include -Istdio -DUSE_SCANSTACK -DPORT_ONLY -D_GNU_SOURCE libschily-mapvers | tr -d '"' | sed 's/^SCHILY/+SCHILY/' | tr '\012'...
-
2018.08.07: libschily-mapvers is empty when building
-
I was not aware that the version of cdrtools inside of schily-tools was meant to be used as a recommended full replament for cdrtools. I suppose the same will then also hold for e.g. star. In this case, the problem is easy to solve: I let the schily-tools ebuild block the cdrtools and star packages and make it the provider for the cdrtools binaries (if the user activates the corresponding USE-flags that he wants that). For cdrtools I just add a dummy ebuild (which forces installation of schily-tools...
-
With changing the dymic linker for ELF support, only one version number has been left in the filename. Not sure what you want to say here: All libraries do it wrong when they indicate backward compatbile changes in minor versions and only libschily does it right by not bumping and relying on override magically always happening in the right order? If you are not able to find a cooperative solution for the cdrtools packagem it is probably the best idea if you always install the shared libschily from...
-
Most libraries use the minor version(s) to indicate backward compatible changes and provide symlinks with major versions only (sometimes even without that) to which consumers of the library actually link. Some random example: lrwxrwxrwx 1 libfdk-aac.so.1 -> libfdk-aac.so.1.0.1 -rwxr-xr-x 1 libfdk-aac.so.1.0.1 lrwxrwxrwx 1 libfdk-aac.so -> libfdk-aac.so.1.0.1 $ ldd /usr/bin/ghb | grep fdk libfdk-aac.so.1 => /usr/lib64/libfdk-aac.so.1 The correct way to handle the problem is to use "make" I would never...
-
I do not care how you call it: Unfortunately, neither the unix file system nor the runtime linker understand the terminology "old version of libschily-1.0" or "new version of libschily-1.0": They simply understand in both cases "/usr/lib/libschily-so.1.0" (unless one plays dirty tricks with wrappers for LDPATH). So in particular, the assertion "the newer version of libschily-1.0 is compatible with with the older version of libschily-1.0 but not vice versa" becomes in practice the assertion "/usr/lib/libschily-1.0...
-
Please version bump libschily
-
schily-tools-2018.05.17 compiles on 32/64 bit without -fno-strict-overflow, so I guess the ticket can be closed. BTW, considering how hesistant clang and gcc implemented spectre fixes, I suppose that the reason for the change in overflow handling are not any security considerations but pure optimization attempts: My guess is that while (a > 0) { while ((t + a) > t) { ... was optimized to while (a > 0) { while (1) { ... which is valid under the assumption that overflow does not happen. What I fail...
-
On 32 and 64 bit the output is: min ll 8000000000000000 max ll 7fffffffffffffff min ull 0 max ull ffffffffffffffff
-
On 32 and 64 bit the output is: min ll 8000000000000000 max ll 7fffffffffffffff min ull 0 max ull ffffffffffffffff
-
This seems to be an indication for a really bad compiler. As mentioned, I had the same problem with clang-6.0.0. I guess the main motivation was that relying on overflow/underflow was the cause of some buffer overflows and other security vulnerabilities when signed types had suddenly become unsigned. I also would have preferred a segfault, but probabably an explicit test was too costly. BTW: did you see that the code tries to avoid such overflows? I never looked at assembler output (actually, I do...
-
Aha: It seeems that the code of gnewtime() is relying on underflow behaviour. In https://gcc.gnu.org/gcc-8/changes.html it says: -fno-strict-overflow is now mapped to -fwrapv -fwrapv-pointer and signed integer overflow is now undefined by default at all optimization levels. Using -fsanitize=signed-integer-overflow is now the preferred way to audit code, -Wstrict-overflow is deprecated. Compiling with -fno-strict-overflow works with gcc-8 on 32 bit.
-
For the working (gcc-7) version, this is the case. For the failing (gcc-8) version, I get on 32 bit gnewtime() = Thu Feb 12 15:07:07 2009 (49942d0b) On 64 bit, the patch causes a segfault with gcc-8 (currently, I no longer have gcc-7 on 64 bit; I would need to recompile it).
-
The output with the two different smake binaries is attached
-
When I stop the loop, the timestamps of the mentioned files appear to be correct: % ls -l --sort=time autoconf -rwxr-xr-x 1 vaeth vaeth 676053 Mai 9 12:32 configure -r--r--r-- 1 vaeth vaeth 32587 Mär 12 21:32 configure.in -r--r--r-- 1 vaeth vaeth 58234 Mär 12 21:31 xconfig.h.in -r--r--r-- 1 vaeth vaeth 1110 Mär 12 20:46 rules.cnf.in -r--r--r-- 1 vaeth vaeth 103193 Jun 28 2017 aclocal.m4 -r--r--r-- 1 vaeth vaeth 87354 Jun 27 2017 acspecific.m4 -r-xr-xr-x 1 vaeth vaeth 20626 Mai 18 2017 config.sub...
-
Endless make/configure loop w/ gcc-8.1.0 and clang-6.0.0 on i686 (32 bit)
1
