From nobody Fri Dec 29 00:06:17 2023 X-Original-To: desktop@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4T1Qdj5NfWz54yYS for ; Fri, 29 Dec 2023 00:06:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4T1Qdj4LKhz3QWN for ; Fri, 29 Dec 2023 00:06:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1703808377; a=rsa-sha256; cv=none; b=HQRgve0HgljgH1cU8IhQju6NnbPwLpHJ4I3sjcdc4ZTT2LsIMX4M80y9X3SQ4dqv94aqyN NFg0mHMDBnsNKnV89bSpNdGQnnRWLF5VSgmup0C1dDv+BTMg9kjzySwpDIR6aCM3+H8iOE o0qXJWhZGuqdcWAAT1dttJzC2dSutmawHJatUnhozKBqV8EZ4E1l9KvMkIH9Ax17KHerXO x8G6089Zx+lEStIXdwIkIAUHqMUMMC47oY/G9gkKPnJdAlaKWHbGjWeeyD0agQpxL7EIIM 79FbkSgrMyzlhQ6ohWqGr4hKGa409X+kNsTiTdHXFpX5WpxF0Po0wkpBjVhNWA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1703808377; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lcgdKUJnl7aUfVORTAgKUdyGmm7PnLdDZI+l+Ek4zWc=; b=Px5EB83K1Yv2IXZiryPN3bnzmbOSsEd0Q/Hy/jQFXNCRaoA6v3IET/8aVi+9VkrpTMmf8Y XnvwmZvzxDxjffIJq2wSyV2zV37PMrSc3UnaQopdE9Lcs74ba05TcplQyZ2O7czaOxzExI HWzq27WLVPoHSe7fwzzjjjnJG2hEuyk2D36Lo5EHTzbk8HIxQX43emjXcbWCdKkTBwM4EK 2BR3F+0i1g0HXvcryY8CttbbFSPzuaw1B1U87zUQ7UhH2bTQUSkUFbp/udJCTZfMCOZWP4 f/pL6e0BhIhAa05jNkP36J9ty7+9R48R0rG8mI3jYoP9HmGlp2LqOpRP/TTBDw== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4T1Qdj3HVlzkWH for ; Fri, 29 Dec 2023 00:06:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 3BT06HES000896 for ; Fri, 29 Dec 2023 00:06:17 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 3BT06Hf4000895 for desktop@FreeBSD.org; Fri, 29 Dec 2023 00:06:17 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: desktop@FreeBSD.org Subject: [Bug 275969] converters/libiconv: Unable to build without including /usr/local/include/iconv.h Date: Fri, 29 Dec 2023 00:06:17 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: rodarima@gmail.com X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: desktop@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Using and improving FreeBSD on the desktop List-Archive: https://lists.freebsd.org/archives/freebsd-desktop List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-desktop@freebsd.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D275969 --- Comment #8 from Rodrigo --- 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 ), 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.=