I'm sure systemd used to build with gcc 7.1 when it was first released /var/tmp/portage/sys-apps/systemd-233-r1/work/systemd-233/src/shared/install.c: In function ‘unit_file_disable’: /var/tmp/portage/sys-apps/systemd-233-r1/work/systemd-233/src/shared/install.c:1007:22: error: argument 1 null where non-null expected [-Werror=nonnull] name = basename(path); ~~~~~^~~~~~~~~~~~~~~~ In file included from /var/tmp/portage/sys-apps/systemd-233-r1/work/systemd-233/src/shared/install.c:28:0: /usr/include/string.h:599:14: note: in a call to function ‘basename’ declared here extern char *basename (const char *__filename) __THROW __nonnull ((1)); ^~~~~~~~ I'm not sure if this warning can be ignored or not
Created attachment 474620 [details] XZ Compressed Build Log
Could you please try to reproduce this with systemd-9999?
Hm, =systemd-233-r1 build and works here fine with gcc-7.1.0 (I have just a rebuild tested)
Do you have anything in your flags that's downgrading the error? It looks like the issue isn't happening with GCC 7.1.1 which is used by RedHat
basename(path) function requires that path is ensured to be not null. I will prepare a patch. *To be clear: gcc 7.1 is working fine.*
The systemd maintainers are adamant that the issue lies in GCC 7.1.0, they're using a Redhat patched version (GCC 7.1.1) which compiles it fine. Please see the systemd bug for more details https://github.com/systemd/systemd/issues/6119
Created attachment 478330 [details, diff] Ensure not-null path to basename function.
Created attachment 478354 [details] emerge --info gcc:7.1.0 systemd (In reply to Mike Lothian from comment #4) > Do you have anything in your flags that's downgrading the error? > > It looks like the issue isn't happening with GCC 7.1.1 which is used by > RedHat Hn no, I have nothing special, build here fine with standard sys-devel/gcc-7.1.0-r1::gentoo compiler. Can you please add your "emerge --info gcc:7.1.0 systemd" to this Bug. And please make a build test with -O2 instead of -O3 optimization.
Created attachment 478424 [details] emerge --info gcc:7.1.0 systemd output
test: -O2 -> success -O3 -> fail
Hm, you using a 17.0 profile with gcc-7.1.0[pie,ssp] I think it is not good idea building packages with ssp on, and -O3 optimization. On gentoo hardened this combination is unsupported - see https://wiki.gentoo.org/wiki/Hardened/FAQ#Why_don.27t_my_programs_work_when_I_use_CFLAGS.3D.22-O3.22_and_hardened_gcc.3F I think with stack-smashing protector (SSP) you should not using -O3 optimization.
(In reply to josef.95 from comment #11) > Hm, you using a 17.0 profile with gcc-7.1.0[pie,ssp] > I think it is not good idea building packages with ssp on, and -O3 > optimization. > On gentoo hardened this combination is unsupported - see > https://wiki.gentoo.org/wiki/Hardened/FAQ#Why_don. > 27t_my_programs_work_when_I_use_CFLAGS.3D.22-O3.22_and_hardened_gcc.3F > > I think with stack-smashing protector (SSP) you should not using -O3 > optimization. I moved from the previous profile without ssp. At this point I will follow your suggestion to keep away from -O3 flag. Furthermore, the proposed patch should be safe because implement a trivial check on a null pointer, even if the same check has been performed by means of an "assert" macro. thanks luigi
I think ssp is enabled by the eclass for all gcc's newer than 6, can you confirm I should be switching this off for O3, or are you recommending that O3 in general should be avoided? There are are few packages that use O3 by default
This was solved upstream via https://github.com/systemd/systemd/commit/fb1b58820fc4622a3b7f54b4096943e4768505cb.patch Please add the patch to gentoo until > systemd-234 is out, thanks. Patched systemd-234 compiled with gcc-7.2.0 and both "-O2" or "-O3" in C(XX)FLAGS.
235 is due out soon, so I'm more inclined to just wait for it.
this should be fixed now
