| Summary: | sys-apps/openrc-0.35: rc.c:349:6: error: implicit declaration of function 'getline' [-Werror=implicit-function-declaration] | ||
|---|---|---|---|
| Product: | Gentoo Hosted Projects | Reporter: | Stephan Hartmann (RETIRED) <sultan> |
| Component: | OpenRC | Assignee: | Gentoo/BSD Team <bsd+disabled> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | base-system, mgorny, openrc |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | FreeBSD | ||
| URL: | https://lists.gnu.org/archive/html/bug-ncurses/2016-11/msg00012.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build log
FreeBSD-posix.patch FreeBSD.patch freebsd.patch ncurses.pc ncurses-gentoo.pc |
||
|
Description
Stephan Hartmann (RETIRED)
2018-03-01 13:08:11 UTC
FreeBSD requires to define _WITH_GETLINE before including stdio.h. Something like this should work: #if defined(__FreeBSD__) && !defined(_WITH_GETLINE) #define _WITH_GETLINE #endif #include <stdio.h> The following commit should fix this and will be in OpenRC 0.35.1. https://github.com/openrc/openrc/commit/10986964 The fix doesn't work. Problem is that somehow _POSIX_C_SOURCE=200112L and _XOPEN_SOURCE=600 added to gcc's command-line. However, both are not defined (and build succeeds) if I call gmake ... directly within openrc's build directory. The defines are set by mk/termcap.mk via pkg-config --cflags ncurses. A workaround could be to remove the include of termcap.mk within src/rc/Makefile, since nothing inside rc uses ncurses. Created attachment 522228 [details, diff]
FreeBSD-posix.patch
Please test with this patch and let me know if it resolves the issue.
Thanks,
William
The best fix would be to fix the ncurses.pc file to not include the unnecessary flags. I could remove them in OpenRC's build system, but that is a hack; ncurses should be fixed. Which versions of ncurses add the inappropriate flags? According to my research, (the getline man page in FreeBSD), the way to access the getline function is to add -D_WITH_GETLINE to the command line. This is done. Please provide a build log that shows any failures when trying to build OpenRC 0.35.3. Thanks, William (In reply to William Hubbs from comment #7) > According to my research, (the getline man page in FreeBSD), the way to > access the getline function is to add -D_WITH_GETLINE to the command > line. This is done. > Then I would suggest you continue your research past the first snippet because this is just a hack to work-around broken _POSIX_C_SOURCE: Applications that wish to use the getline() function described herein should either request a strict IEEE Std 1003.1-2008 (``POSIX.1'') environment by defining the macro _POSIX_C_SOURCE to the value 200809 or greater, or by defining the macro _WITH_GETLINE, prior to the inclusion of <stdio.h>. I did see that, and it seems to imply that I can define either macro. It looks like _BSD_SOURCE is probably a good way to go for this. Otherwise I'll end up rewriting at least vsyslog and strsep. Please test with 0.35.4 and report back. It turned out that I need _BSD_SOURCE because we use vsyslog and strsep which are not posix c. 0.35.5 has been in the tree for several days now, so I need to know whether it builds on FreeBSD. Could someone test and let me know? Thanks, William (In reply to William Hubbs from comment #12) > 0.35.5 has been in the tree for several days now, so I need to know > whether it builds on FreeBSD. > > Could someone test and let me know? > > Thanks, > > William Still doesn't work. Created attachment 530390 [details, diff]
FreeBSD.patch
Please test with this patch against 0.35.5 and let me know if it builds.
Thanks,
William
I am adding base-system to this bug since the issue is in ncurses. Well, the patch either fixes it or triggers another error before it:
x86_64-gentoo-freebsd11.1-gcc -fPIC -DPIC -I../includes -D_BSD_SOURCE -D_POSIX_C_SOURCE=200809L -O2 -pipe -march=native -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 -Werror=implicit-function-declaration -c librc.c -o librc.So
In file included from /usr/include/machine/pcb.h:7:0,
from /usr/include/sys/user.h:38,
from librc.h:49,
from librc.c:21:
/usr/include/machine/amd64_fbsd/pcb.h:79:2: error: unknown type name ‘u_int’
u_int pcb_flags;
^~~~~
In file included from /usr/include/sys/user.h:44:0,
from librc.h:49,
from librc.c:21:
/usr/include/sys/ucred.h:84:2: error: unknown type name ‘u_int’
[...]
Created attachment 530642 [details, diff]
freebsd.patch
Ok, try this patch.
Let me know if it works.
Thanks,
William
Fails the same as previous. I was just advised on the #freebsd-ports channel that OpenRC 0.35.5 and HEAD build successfully on native FreeBSD version 11-stable a couple of months old. So, does anyone have any suggestions? This keeps happening with sys-apps/openrc-0.36 As I stated above, I was advised that OpenRC builds fine on native FreeBSD. It seems like this might be because of a custom patch we carry which has not been upstreamed in FreeBSD. Thanks, William OK I've tried something silly which is to comment out the current src_compile() function and define another one which looks like this:
src_compile() {
gmake
}
Now, compilation works out fine. I think something is up in some of the args given to make/gcc throug emake. Could someone else confirm?
*through Created attachment 536742 [details]
ncurses.pc
This is ncurses.pc from a native FreeBSD system.
Created attachment 536744 [details]
ncurses-gentoo.pc
This is the ncurses.pc from a Gentoo/FreeBSD system.
This is how upstream ncurses writes their *.pc files. However, this is
incorrect as shown in the discussion linked in the see also section of
this bug.
This is definitely a ncurses bug rather than an OpenRC bug.
Thanks,
William
|
