MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Thu, 22 Sep 2022 23:46:41 +0200
Message-Id: <CN39DAN9TFUE.34UH7VT4KJIVC@sumire>
To: "Riccardo Mottola" <riccardo.mottola@libero.it>, "alpine-user"
 <alpine-user@lists.alpinelinux.org>
Subject: Re: iconv detection issues
From: "alice" <alice@ayaya.dev>
References: <34652592-dd13-dca0-40a1-18eb43101bd9@libero.it>
 <CN24O9AIQA5Y.1N9K8QRIAUFE3@sumire>
 <4473ae75-aa82-48a3-c7dc-833853304428@libero.it>
In-Reply-To: <4473ae75-aa82-48a3-c7dc-833853304428@libero.it>

On Thu Sep 22, 2022 at 11:40 PM CEST, Riccardo Mottola wrote:
> Hi Alice,
>
> alice wrote:
> >> conftest.c:235:48: warning: comparison between pointer and integer
> >> =C2=A0 235 | { return iconv_open("UTF-8//TRANSLIT","ASCII") =3D=3D -1 =
? 1 : 0; }
> > the TRANSLIT extension is not supported by musl iconv.
> > see: https://wiki.musl-libc.org/functional-differences-from-glibc.html#=
iconv
> >
> > so, the configure test fails. if the program hard-requires this
> > support, then you can try use gnu-libiconv(-dev), and see how to link
> > that (i don't know if it's actually the same api/kind of thing..) by
> > modifying the configure files, passing flags, etc.
>
> very good, indeed, using gnu-libiconv-dev and then fiddling with the
> include headers, made configure work.
> Linking should be fine, because the library is installed then in the
> usual place /usr/local/lib
>
> However, linking fails. At a first glance, not only iconv, but symbols
> of almost all libraries are missing:
> ...
> /usr/lib/gcc/i586-alpine-linux-musl/11.2.1/../../../../i586-alpine-linux-=
musl/bin/ld:
> /home/multix/code/libs-base/Source/GSTLS.m:2314: undefined reference to
> `gnutls_x509_crt_init'
>
> ...
> ression.m:744: undefined reference to `uregex_close_71'
> /usr/lib/gcc/i586-alpine-linux-musl/11.2.1/../../../../i586-alpine-linux-=
musl/bin/ld:
> /home/multix/code/libs-base/Source/NSRegularExpression.m:744: undefined
> reference to `uregex_lookingAt_71'
> ...
> /home/multix/code/libs-base/Source/GSFileHandle.m:298: undefined
> reference to `gzread'
> /usr/lib/gcc/i586-alpine-linux-musl/11.2.1/../../../../i586-alpine-linux-=
musl/bin/ld:
> ../Source/./obj/libgnustep-base.a(GSFileHandle.m.o): in function
> `_i_GSFileHandle__write_length_':
>
>
> looks to me like ICU, gzip, gnutls... like all linking failing! wow a
> hint where this could be different from other linux?
no idea, but it sounds like the thing you are compiling forgets to link
everything at all, or expects to only load it at runtime in some fashion
and intentionally doesn't link it (iirc something about musl not
supporting this lazy loading? but i don't know much about it:) ). i'd
guess manually adding -lgnutls etc etc would fix them by linking
correctly at build time?

(or, your adjustments to the build broke all of that linking somehow)
>
> Riccardo