Bug 273354
| Summary: | x11/libinput: fails to build on stable/14 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Kenneth Raplee <kenrap> | ||||||
| Component: | Individual Port(s) | Assignee: | freebsd-x11 (Nobody) <x11> | ||||||
| Status: | Closed FIXED | ||||||||
| Severity: | Affects Only Me | CC: | imp, junchoon, madpilot, manu, marklmi26-fbsd | ||||||
| Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(x11) |
||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| URL: | https://gitlab.freedesktop.org/libinput/libinput/-/issues/931 | ||||||||
| Attachments: |
|
||||||||
Created attachment 244358 [details]
Successful build log on baremetal stable14, amd64
I've bitten by the exactly same problem on poudriere.
But with `make` on baremetal environment built successfully.
This could mean some unspecified (insufficient) dependency which is implicitly detected on baremetal environment.
Uploaded successful build log on baremetal (non-poudriere-jail) environment.
Note that I've upgraded base, finished delete-old and etcupdate but not yet delete-old-libs. Following upgrade for kmod ports before final reboot (from single user), but all other ports are not yet updated (builds are ongoing inside poudriere jail).
So successful build was done on mixed environment (base is up-to-date, but most ports are still built on stable/13 running with not yet deleted stable/13 libraries.
Base is at commit 2af9390e54edfe1da9dc909a1a03088df5896eba.
Hi Tomoaki, Actually, I recently did an experiment by creating a patch that changes the `NOFILE` constant with `NO_FILE` and I got it to build successfully with poudriere on my base build at 2af9390e54edfe1da9dc909a1a03088df5896eba. I was thinking about opening a PR on GitHub with this revision. Should I hold off though if this is not the proper fix? (In reply to Kenneth Raplee from comment #2) I've seen this with recent head (post 15). I've fixed in an almost identical way (I used a different name) I noticed this is caused by the addition of /usr/include/sys/timerfd.h in https://cgit.freebsd.org/src/commit/?id=af93fea710385b2b11f0cabd377e7ed6f3d97c34 libinput includes this file, but the new file causes /usr/include/sys/param.h to also be included, that defines NOFILE, producing this error. Since that NOFILE definition is local to that source file, I think this is the correct fix. I'm posting a patch shortly to help the maintainer. Created attachment 244360 [details]
Proposed fix v1
Attaching patch with proposed fix.
Thanks in advance!
(In reply to Kenneth Raplee from comment #2) Actually, I have main (current) environment in different drive on the exactly same PC. I don't use poudriere on main (often bumped, meaning that I'm forced to rebuild all ports), so I couldn't notice this issue. My main environment is at commit 0d30f3afa62b4740810006476eb9de0c480619a1, before stable/14 branched. If the pull request is for upstream, please go for it. They will accept it if they're open for FreeBSD-specific (maybe ifdef'ed) fix and consider it as proper fix. If not, they will reject with (hopefully) some helpful info or silently ignore it. If iy's for FreeBSD project as this PR, please note this PR there and feedback here which pull request is for this, not to confuse developers/maintainers. But I still suspect this could be dependency hell, as poudriere is a clean-room builder, and *Deletes all pre-built pkgs that poudriere consders rebuild is needed before starting build jails, *Extract EXPLICITLY required pkgs on each jail and clean up before next build. Because of this, poudriere cannot know implicit dependency, and if it handles something instead of base, configure scripts or something alike would missingly pulls in base components, thus resulting build issues. (In reply to Tomoaki AOKI from comment #5) The commit I referenced, which adds a timerfd implementation to FreeBSD, and so add a timerfd.h file to out includes, happened shortly before stable/14 was branched. The problem will happen to anyone trying to compile libinput on FreeBSD installed from sources after that commit. SO it applies to head after that commit (14 for a short while later renamed to 15) and also to stable/14. This simple patch fixes the issue. I'm not sure what you mean by dependency hell. poudriere usage has no relation to this, this only depends on the presence of the new timerfd.h include in the installed system. If no such include is present in the installed system, the port will grab the one installed by devel/libepoll-shim which was recently fixed to work on head after this commit. The timerfd.h installed by it does not cause params.h to be included and no NOFILE symbol is defined. Please note that devel/libepoll-shim will not install any timerfd.h file on systems that already have one. So, this patch should be included in FreeBSD, and x11@ declared a one week timeout is of with their ports, so I'll respect that. This should also be sent upstream, if Kenneth Raplee wants to do it please go ahead. Fix looks good to me, please submit it upstream too :) (In reply to Guido Falsi from comment #6) Ah, make sense. I've built fixed devel/libepoll-shim in poudriere but not actually updated (installed), so timerfd.h installed by it (built on stable/13) is still there. Thanks for noting this. Tried uploaded patch and it built fine on poudriere. Thanks! Hi folks, Sorry for the late response! I was away for a bit. I went ahead and sent the PR upstream as suggested: https://github.com/freebsd/freebsd-ports/pull/190 And thanks for checking on and confirming about my proposed fix. It's appreciated! (In reply to Kenneth Raplee from comment #9) Hmm: https://docs.freebsd.org/en/articles/contributing/ reports: "Pull requests submitted to the ports repository may or may not see action, based on the whims of developers. For now, you will have a better experience if you follow the ports submission process Contributing to ports." May be x11/ is handling pull requests? (In reply to Mark Millard from comment #10) Thanks for sharing that. I'm still confused though. It seems that in various other places of that article, it keeps mentioning about submitting PRs for updates or fixes as if that's seemly the way to go? For ports, the preferred way is to do a git format-patch as an attachment. Pull requests are done, but it is hit or miss. (In reply to Warner Losh from comment #12) Ah, gotcha. Then should I close my GitHub PR then? The patch attached by Guido Falsi does the same thing. (In reply to Kenneth Raplee from comment #11) When I said "submitting PR upstrem" i meant submitting to the "upstream" repo, in this case libinput project's repo. IN the FreeBSD ports context "upstream" means the actual developers of the software being ported. I"m going to commit my patch shortly. Tomorrow I'll look at libinput patch submission guidelines. A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=5e70841f87b2d316acc170b0f550e4eab205b6e2 commit 5e70841f87b2d316acc170b0f550e4eab205b6e2 Author: Guido Falsi <madpilot@FreeBSD.org> AuthorDate: 2023-08-26 22:47:17 +0000 Commit: Guido Falsi <madpilot@FreeBSD.org> CommitDate: 2023-08-26 22:47:17 +0000 x11/libinput: Add patch to fix build on recent head This fixes build after src commit af93fea710385b2b11f0cabd377e7ed6f3d97c34 PR: 273354 Approved by: x11 (manu) .../files/patch-tools_libinput-record.c (new) | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) Patch committed. Thanks all! Reported upstream: https://gitlab.freedesktop.org/libinput/libinput/-/issues/931 I'm not authorized to create merge requests right now, but I'll followup there once I get the permission. After review D41641 (see also bug 273373) the fix here can be dropped as the error won't be reproducible: <sys/timerfd.h> -> <sys/proc.h> (no longer included) -> <sys/ucred.h> -> <bsm/audit.h> -> <sys/param.h> -> error. Renaming upstream may still be useful: glibc and musl (unlike bionic) also have NOFILE in <sys/param.h>. |
I think this affects both 14 and 15 users and it's related to libepoll-shim since it was recently fixed. FAILED: libinput-record.p/tools_libinput-record.c.o cc -Ilibinput-record.p -I. -I.. -I../src -I../include -I/usr/local/include/libepoll-shim -I/usr/local/include -I/usr/local/include/libevdev-1.0 -I/usr/local/include/libwacom-1.0 -I/usr/local/include/gudev-1.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -fno-color-diagnostics -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=gnu99 -Wno-unused-parameter -Wmissing-prototypes -Wstrict-prototypes -Wundef -Wpointer-arith -Wuninitialized -Winit-self -Wstrict-prototypes -Wimplicit-fallthrough -Wredundant-decls -Wincompatible-pointer-types -Wformat=2 -Wno-missing-field-initializers -Wmissing-declarations -fvisibility=hidden -O2 -pipe -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -MD -MQ libinput-record.p/tools_libinput-record.c.o -MF libinput-record.p/tools_libinput-record.c.o.d -o libinput-record.p/tools_libinput-record.c.o -c ../tools/libinput-record.c ../tools/libinput-record.c:2580:2: error: expected identifier NOFILE, ^ /usr/include/sys/param.h:133:17: note: expanded from macro 'NOFILE' #define NOFILE OPEN_MAX /* max open files per process */ ^ /usr/include/sys/syslimits.h:60:22: note: expanded from macro 'OPEN_MAX' #define OPEN_MAX 64 /* max open files per process */ ^ 1 error generated.