martin.vaeth

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/...