Date: Fri, 29 Dec 2023 00:06:17 +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-mnGa7vAOQ8@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 #8 from Rodrigo <rodarima@gmail.com> --- Hi, > > I'm guessing libiconv and libc try to provide compatible headers, but i= t=20 > > seems a bit fragile to depend on that. > What's the problem with this approach? This is exactly what Ports framewo= rk do.=20 > By passing -DLIBICONV_PLUG you make it indifferent for the software you'r= e=20 > 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 ju= st > use that for your CI. FWIW, the www/dillo2 port does include=20 > /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 infrastructu= re for=20 > you continuous integration setup. I guess that's a reasonable goal for t= he=20 > 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 u= se > '-isystem /usr/include' or '-isystem /usr/include -isystem /usr/local/inc= lude'. > > 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/op= enssl > (vs /usr/include/openssl). > > Any time you have two choices for a library on any platform, you are goin= g 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 (th= ere > are ways to do this). That is why I was suggesting to maybe install libiconv in a prefixed path l= ike /usr/local/include/libiconv/, so only one iconv.h header is present in eith= er /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 ju= st use: CPPFLAGS=3D"-I/usr/local/include/libiconv" LDFLAGS=3D"-I/usr/local/lib/li= biconv"=20 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 lib= c, or use the plug flag. > Usually on FreeBSD in these situations for building most upstream project= s, > 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 & /u= sr/lib) > and also in LOCALBASE. That's what I had in mind too. --=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-mnGa7vAOQ8>