sparc64-gentoo-freebsd9.0-gcc -w -O2 -mcpu=ultrasparc3 -mtune=ultrasparc3 -fno-strict-aliasing -pipe -std=c99 -Wall -Wextra -Wimplicit -Wshadow -Wformat=2 -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wmissing-format-attribute -Wnested-externs -Winline -Wwrite-strings -Wcast-align -Wcast-qual -Wpointer-arith -Wdeclaration-after-statement -Wsequence-point -I../includes -I../librc -I../libeinfo -DHAVE_TERMCAP -c checkpath.c -o checkpath.o checkpath.c:35:22: error: features.h: No such file or directory gmake[2]: *** [checkpath.o] Error 1 gmake[2]: *** Waiting for unfinished jobs.... gmake[2]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.9.8.1/work/openrc-0.9.8.1/src/rc' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/var/tmp/portage/sys-apps/openrc-0.9.8.1/work/openrc-0.9.8.1/src' gmake: *** [all] Error 2 features.h is in glibc but not in freebsd-libc
Features.h was introduced in commit 66f4305. It looks like we need to rework this so it is cross-platform.
Created attachment 299503 [details] remove-features-h.patch This patch removes the include for features.h. I tested this here and it worked fine on my linux setup. Can you apply this and see if it compiles for you on *bsd? @robbat2: Why do we need to include features.h? The code seems to compile fine without it. William
It compiles fine without features.h Tibor
(In reply to comment #2) > Created attachment 299503 [details] > remove-features-h.patch > > This patch removes the include for features.h. I tested this here and it > worked fine on my linux setup. > > Can you apply this and see if it compiles for you on *bsd? > > @robbat2: > Why do we need to include features.h? The code seems to compile fine > without it. > > William We need features.h because of the macro used in checkpath.c and actually we need it in rc-misc.h as well as libeinfo.c. In checkpath.c it's the __USE_XOPEN2K8 macro, in the other two it's the __GLIBC__ macro. For __GLIBC__ we currently rely on the stdlib.h include but it seems it's not 100% guaranteed that features.h will be included there.
(In reply to comment #4) > (In reply to comment #2) > > Created attachment 299503 [details] > > remove-features-h.patch > > > > This patch removes the include for features.h. I tested this here and it > > worked fine on my linux setup. > > > > Can you apply this and see if it compiles for you on *bsd? > > > > @robbat2: > > Why do we need to include features.h? The code seems to compile fine > > without it. > > > > William > > We need features.h because of the macro used in checkpath.c and actually we > need it in rc-misc.h as well as libeinfo.c. > In checkpath.c it's the __USE_XOPEN2K8 macro, in the other two it's the > __GLIBC__ macro. For __GLIBC__ we currently rely on the stdlib.h include but it > seems it's not 100% guaranteed that features.h will be included there. This means that elibc*bsd support will be dropped from openrc?
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #2) > > > Created attachment 299503 [details] > > > remove-features-h.patch > > > > > > This patch removes the include for features.h. I tested this here and it > > > worked fine on my linux setup. > > > > > > Can you apply this and see if it compiles for you on *bsd? > > > > > > @robbat2: > > > Why do we need to include features.h? The code seems to compile fine > > > without it. > > > > > > William > > > > We need features.h because of the macro used in checkpath.c and actually we > > need it in rc-misc.h as well as libeinfo.c. > > In checkpath.c it's the __USE_XOPEN2K8 macro, in the other two it's the > > __GLIBC__ macro. For __GLIBC__ we currently rely on the stdlib.h include but it > > seems it's not 100% guaranteed that features.h will be included there. > > This means that elibc*bsd support will be dropped from openrc? No! We just need a proper solution. Another case were autotools would make sense.
Created attachment 299553 [details] fix-features-h.patch Christian, what do you think of this patch that will only include features.h on linux?
In my previous patch, s/__LINUX__/__linux__/. That gives the correct symbol.
This is why we need features.h: #ifdef __USE_XOPEN2K8 flags |= O_CLOEXEC|O_NOFOLLOW; #endif Those come from the systemd tmpfiles code. O_CLOEXEC is there to avoid some race conditions. O_NOFOLLOW prevents some symlink attacks. O_NOFOLLOW is from FreeBSD originally, but I don't know if a specific header is needed there to use it. At least one of the BSD libc's gained O_CLOEXEC within the last 12 months, likewise, I don't know what header needs to be used for it.
In FreeBSD the /usr/include/fcntl.h header file contains O_NOFOLLOW and O_CLOEXEC definitions.
(In reply to comment #9) > This is why we need features.h: > #ifdef __USE_XOPEN2K8 > flags |= O_CLOEXEC|O_NOFOLLOW; > #endif > > Those come from the systemd tmpfiles code. O_CLOEXEC is there to avoid some > race conditions. O_NOFOLLOW prevents some symlink attacks. @robbat2: I just did a grep through the systemd code, and there are no references to features.h. I am running openrc head now, which has that include dropped, and it works fine here. What is the issue you are running into without it?
(In reply to comment #9) > This is why we need features.h: > #ifdef __USE_XOPEN2K8 > flags |= O_CLOEXEC|O_NOFOLLOW; > #endif > > Those come from the systemd tmpfiles code. O_CLOEXEC is there to avoid some > race conditions. O_NOFOLLOW prevents some symlink attacks. > > O_NOFOLLOW is from FreeBSD originally, but I don't know if a specific header is > needed there to use it. > > At least one of the BSD libc's gained O_CLOEXEC within the last 12 months, > likewise, I don't know what header needs to be used for it. We're using O_CLOEXEC already in some other sources so we may don't need the __USE_XOPEN2K8 check for it. There were no complains about it.
(In reply to comment #11) > (In reply to comment #9) > > This is why we need features.h: > > #ifdef __USE_XOPEN2K8 > > flags |= O_CLOEXEC|O_NOFOLLOW; > > #endif > > > > Those come from the systemd tmpfiles code. O_CLOEXEC is there to avoid some > > race conditions. O_NOFOLLOW prevents some symlink attacks. > > @robbat2: > I just did a grep through the systemd code, and there are no references to > features.h. > > I am running openrc head now, which has that include dropped, and it works fine > here. > > What is the issue you are running into without it? I guess he just needs our chat log. ;)
for the record, no user code should *ever* rely on __XXX defines from glibc's feature.h. that is always doomed to break. doing this is fine: #ifdef O_CLOEXEC ... do O_CLOEXEC stuff ... #endif (not that this means you can assume the running *kernel* supports O_CLOEXEC, but i don't think that matters too much in the checkpath code since we don't fork and so O_CLOEXEC usage is pointless, and i don't think we need to worry about the "applet" aspect) systemd not using features.h isn't relevant in any way that i can see at any rate, this seems to be fixed in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=e3d0fe06bd566b659a7c36b5d9892c6f6b9caa89 Robin: can you line wrap your commit messages please ?
(In reply to comment #14) > systemd not using features.h isn't relevant in any way that i can see The only way it was relevant to me was that I noticed systemd does use O_CLOEXEC and O_NOFOLLOW without including features.h. Also, the glibc documentation states that this file is included automatically. That is how I knew there was a better way to access these definitions. > at any rate, this seems to be fixed in git now: > http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=commitdiff;h=e3d0fe06bd566b659a7c36b5d9892c6f6b9caa89 Correct, so I am closing this bug.
Why don't you remove KEYWORDS="~x86-fbsd" from 0.9.8.* ebuilds?
(In reply to comment #16) > Why don't you remove KEYWORDS="~x86-fbsd" from 0.9.8.* ebuilds? Why should we? We want bug reports from those users.
(In reply to comment #17) > (In reply to comment #16) > > Why don't you remove KEYWORDS="~x86-fbsd" from 0.9.8.* ebuilds? > Why should we? We want bug reports from those users. Excuse me, I don't understand. All >=sys-apps/openrc-0.9.8.1 fails to compile on g/fbsd because of missing features.h. That is this bug about. This bug closed by comment 15 because fixed in git, but not in ebuilds already in tree. I think it's correct to mask house ebuilds. Which bug reports I should write?
(In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > Why don't you remove KEYWORDS="~x86-fbsd" from 0.9.8.* ebuilds? > > Why should we? We want bug reports from those users. > > Excuse me, I don't understand. All >=sys-apps/openrc-0.9.8.1 fails to compile > on g/fbsd because of missing features.h. That is this bug about. This bug > closed by comment 15 because fixed in git, but not in ebuilds already in tree. > I think it's correct to mask house ebuilds. Which bug reports I should write? sSo 0.9.8.4 doesn't compile on fbsd? 0.9.9 is going to be released in the next day or so and that should take care of this, so there is no need to write a bug report.
(In reply to comment #19) > sSo 0.9.8.4 doesn't compile on fbsd? Yes, and with same messages > 0.9.9 is going to be released in the next day or so and that should take care > of this, so there is no need to write a bug report. I'm waiting for it.
(In reply to comment #19) > (In reply to comment #18) > > (In reply to comment #17) > > > (In reply to comment #16) > > > > Why don't you remove KEYWORDS="~x86-fbsd" from 0.9.8.* ebuilds? > > > Why should we? We want bug reports from those users. > > > > Excuse me, I don't understand. All >=sys-apps/openrc-0.9.8.1 fails to compile > > on g/fbsd because of missing features.h. That is this bug about. This bug > > closed by comment 15 because fixed in git, but not in ebuilds already in tree. > > I think it's correct to mask house ebuilds. Which bug reports I should write? > > sSo 0.9.8.4 doesn't compile on fbsd? > > 0.9.9 is going to be released in the next day or so and that should take care > of this, so there is no need to write a bug report. # eix openrc [U] sys-apps/openrc Available versions: (~)0.8.3-r1 (~)0.9.4 (~)0.9.8.4 **9999 ... No 0.9.8 that works, no 0.9.9, but portage still proposes to update to 0.9.8.4.
(In reply to comment #21) > [U] sys-apps/openrc > Available versions: (~)0.8.3-r1 (~)0.9.4 (~)0.9.8.4 **9999 > ... > No 0.9.8 that works, no 0.9.9, but portage still proposes to update to 0.9.8.4. That's correct. A bug was found in the final stage of testing that blocked the release; it is being worked on.
