New irssi-1.2.0 seems to have an automagic dep on dev-libs/libutf8proc. If this package is installed & detected during configure, later on in the build it will look for <utf8proc.h>, failing because we actually have it at libutf8proc/utf8proc.h checking for utf8proc_version in -lutf8proc... yes ... x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src -I../../src/core -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -DSYSCONFDIR=\""/etc"\" -DMODULEDIR=\""/usr/lib64/irssi/modules"\" -O2 -pipe -march=native -Wall -c -o write-buffer.o write-buffer.c wcwidth-wrapper.c:30:10: fatal error: utf8proc.h: No such file or directory #include <utf8proc.h> ^~~~~~~~~~~~
please post the full emerge --info and the build log, this is currently confusing and I can not repeat
Created attachment 564934 [details] build.log If dev-libs/libutf8proc is installed, "emerge =irssi-1.2.0" will fail
Created attachment 564936 [details] emerge --info
mhm, now I see indeed
*** Bug 677808 has been marked as a duplicate of this bug. ***
FWIW I can successfully build with libutf8proc if i copy or symlink that 'missing' header to /usr/include/utf8proc.h
I just received the same error. The problem seems to be dev-libs/libutf8proc is the wrong libutf8proc in the first place. That package is from netsurf, while irssi is using an implementation from julia: https://github.com/JuliaStrings/utf8proc
Yeah that's a bit odd that we have only packaged the netsurf one. From their README: libutf8proc =========== This is the Public software group utf8proc library [1] repackaged as a conveniance library for NetSurf. Previously this library was simply copied into the NetSurf sources. This takes the unicode 11 capable version 2.2.0 of the library and converts it to the NetSurf build system which adds the generation of a pkg-config file. There are no code changes from upstream. All the Makefiles and changes are licenced as per the utf8proc source using the MIT "expat" licence. [1] https://github.com/JuliaStrings/utf8proc
(In reply to Daniel M. Weeks from comment #7) > I just received the same error. The problem seems to be dev-libs/libutf8proc > is the wrong libutf8proc in the first place. That package is from netsurf, > while irssi is using an implementation from julia: > https://github.com/JuliaStrings/utf8proc speaking of headers there is no difference between netserf and julia ones
(In reply to Mikle Kolyada from comment #9) > (In reply to Daniel M. Weeks from comment #7) > > I just received the same error. The problem seems to be dev-libs/libutf8proc > > is the wrong libutf8proc in the first place. That package is from netsurf, > > while irssi is using an implementation from julia: > > https://github.com/JuliaStrings/utf8proc > > speaking of headers there is no difference between netserf and julia ones That's not the relevant point. They are packaged with two different Makefiles which place the header in different locations. Downstream expectations are going to be different for each depending on which packaging they track *which is how this problem occurred*. Gentoo should probably place the header in the true upstream location and fix bad packages rather than the other way around. But that's outside the scope of this ticket...
(In reply to Daniel M. Weeks from comment #10) > (In reply to Mikle Kolyada from comment #9) > > (In reply to Daniel M. Weeks from comment #7) > > Gentoo should probably place the header in the true upstream location and > fix bad packages rather than the other way around. But that's outside the > scope of this ticket... No. Upstream can do whatever with each release, this is pointless to fix a package A because a package B demands one location today but can demand different location in 2 weeks
Should be fixed with a revbump
Are you sure we want to be patching all our libutf8proc consumers to use the netsurf-forked version instead of the true upstream? Seems more like we should fix netsurf to use the non-forked one. Also, your patch doesn't have libutf8proc in DEPEND, I think this is wrong.
(In reply to Ben Kohler from comment #13) > Are you sure we want to be patching all our libutf8proc consumers to use the > netsurf-forked version instead of the true upstream? Seems more like we > should fix netsurf to use the non-forked one. I will track it for time, and only act if something is really broken. > > Also, your patch doesn't have libutf8proc in DEPEND, I think this is wrong. No, irssi can be built w/o libutf8proc at all
(In reply to Mikle Kolyada from comment #14) > (In reply to Ben Kohler from comment #13) > > Are you sure we want to be patching all our libutf8proc consumers to use the > > netsurf-forked version instead of the true upstream? Seems more like we > > should fix netsurf to use the non-forked one. > > I will track it for time, and only act if something is really broken. > > > > > Also, your patch doesn't have libutf8proc in DEPEND, I think this is wrong. > > > No, irssi can be built w/o libutf8proc at all It will automagically depend on it if it is present at built time. Yes, it does need to be in (R)DEPEND otherwise portage is free to remove libutf8proc underneath it.
*** Bug 677812 has been marked as a duplicate of this bug. ***
