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

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

John Hein <jcfyecrayz@liamekaens.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jcfyecrayz@liamekaens.com

--- Comment #7 from John Hein <jcfyecrayz@liamekaens.com> ---
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.

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

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