[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 #8 from Rodrigo <rodarima@gmail.com> ---
Hi,

> > I'm guessing libiconv and libc try to provide compatible headers, but it 
> > seems a bit fragile to depend on that.

> What's the problem with this approach? This is exactly what Ports framework do. 
> By passing -DLIBICONV_PLUG you make it indifferent for the software you're 
> compiling whether 3rd party libiconv is installed or not.

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.

Using the plug flag relies on the promise that the libiconv header is
compatible with the libc implementation, which may be fine, but I cannot
choose otherwise.

> Doesn't dillo already build via the www/dillo2 port?  And so you could just
> use that for your CI.  FWIW, the www/dillo2 port does include 
> /usr/local/include/iconv.h (and does build with -DDLIBICONV_PLUG).
> And it does not link with /usr/local/lib/libiconv.so.
>
> Maybe you are trying to avoid depending on the FreeBSD ports infrastructure for 
> you continuous integration setup.  I guess that's a reasonable goal for the 
> upstream CI.

Yes, it should build reasonably fine from source directly, which is what we
test
in the CI.

> That said, if you want to coerce the build to include /usr/include/iconv.h
> instead of /usr/local/include/iconv.h (for #include <iconv.h>), you can use
> '-isystem /usr/include' or '-isystem /usr/include -isystem /usr/local/include'.
>
> That may work for using /usr/include/iconv.h (vs /usr/local/include/iconv.h).
> But it may not work if you wanted header files from /usr/local/include/openssl
> (vs /usr/include/openssl).
>
> Any time you have two choices for a library on any platform, you are going to
> run into potential conflicts that may be hard to resolve unless the build
> system for a project is set up specifically to support such an option (there
> are ways to do this).

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.

By default it will just include /usr/include/iconv.h and link with the libc
(which is what I would expect). But if I wanted to use libiconv, I could just
use:

  CPPFLAGS="-I/usr/local/include/libiconv" LDFLAGS="-I/usr/local/lib/libiconv" 

With no risk of accidentally including libiconv headers when adding
/usr/local/include for other ports.

I understand that this may require a lot of rebuilds for depending packages,
and that using the -DLIBICONV_PLUG flag may be a good compromise.

My comment was to manifest that this situation is happening, and I think it
should be changed eventually.

In Dillo I can either link with libiconv if I detect it before checking libc,
or use the plug flag.

> 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.

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