[Bug 275969] converters/libiconv: Unable to build without including /usr/local/include/iconv.h

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275969

--- 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, it'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 system
include files in /usr/include before /usr/local/include.  And neither of those
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 files.
 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 either
> /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 FreeBSD
ports that are currently able to build with the current libiconv pkg to look 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 freebsd
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 the
desired iconv.h.  Then the existing -I (or -isystem) flags that point to paths
within the dillo build area would be sufficient.  That might be the easiest
path.


> > Usually on FreeBSD in these situations for building most upstream projects,
> > it is most manageable to prefer the libs / include files in LOCALBASE if 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.