Date: Fri, 29 Dec 2023 03:04:04 +0000 From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 275969] converters/libiconv: Unable to build without including /usr/local/include/iconv.h Message-ID: <bug-275969-39348-nHgzG5pKN2@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-275969-39348@https.bugs.freebsd.org/bugzilla/> References: <bug-275969-39348@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275969 --- Comment #9 from John Hein <jcfyecrayz@liamekaens.com> --- (In reply to Rodrigo from comment #8) > The problem is that I don't have a choice to include /usr/include/iconv.h > instead of /usr/local/include/iconv.h while using FLTK. Of course you have a choice. But the way the dillo build is constructed, i= t's just harder. The only source files that include <iconv.h> are src/decode.c= and src/form.cc. Those are the only files that need to prefer searching for sy= stem include files in /usr/include before /usr/local/include. And neither of th= ose files need fltk header files. So you CAN build a project with /usr/include/iconv.h and /usr/local/include/FL/*.h. It's just more difficult the way dillo's build = is set up. Some projects support different -I options for different source fi= les. Dillo [right now] is just not one of those such projects. > That is why I was suggesting to maybe install libiconv in a prefixed path= like > /usr/local/include/libiconv/, so only one iconv.h header is present in ei= ther > /usr/include or /usr/local/include. That's not an unreasonable setup (other projects do that: e.g., /usr/local/include/openssl, /usr/local/include/apache24, /usr/local/include= /nss to name just a few). But it's probably a heavier lift to get all the FreeB= SD ports that are currently able to build with the current libiconv pkg to loo= k in /usr/local/include/libiconv instead of /usr/local/include. Maybe with a strategic change in Mk/Uses/iconv.mk, it might be not be too bad. It also might not be too hard to modify the dillo build to support using a different set of -I options to the build of src/form.cc and src/decode.c. = I'm not sure which would be more easily get accepted (dillo build change or fre= ebsd change to converters/libiconv). But first step is to come up with a patch = and get it reviewed. Yet another option... Here's another option. Create a sym link in the build area that point to t= he desired iconv.h. Then the existing -I (or -isystem) flags that point to pa= ths within the dillo build area would be sufficient. That might be the easiest path. > > Usually on FreeBSD in these situations for building most upstream proje= cts, > > it is most manageable to prefer the libs / include files in LOCALBASE i= f there > > is a choice that exists in both the base system (/usr/include & /lib & = /usr/lib) > > and also in LOCALBASE. > > That's what I had in mind too. Then just use the the the headers / libs from the libiconv pkg for the iconv needs instead of libc & /usr/include/iconv.h. You are already dependent on= one package (fltk). What's one more? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-275969-39348-nHgzG5pKN2>