Dependence of libgd on iconv

[Michael Orlitzky]

Our libgd package depends on iconv:

$ cat build/pkgs/libgd/dependencies
libpng freetype iconv
...

Does anyone remember why? It's possible to build libgd without iconv as
far as I can tell (check CMakeLists.txt), and the only consequence I see
is that some functions in libgd's src/gdkanji.c get defined out.

[Dima Pasechnik]

iconv is only installed on Cygwin anyway (apart from surely dead HP
port, and fallen behind Solaris port,
which probably no longer needs it anyway).
So this is a red herring one way or another.

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/47a2d396-cbff-b4a1-7f1d-f8f83c2d66e6%40orlitzky.com.
> For more options, visit https://groups.google.com/d/optout.

[Jeroen Demeyer]

On 2019-05-13 15:51, Michael Orlitzky wrote:
> It's possible to build libgd without iconv as
> far as I can tell (check CMakeLists.txt)

A dependency is not the same as a requirement. If it's used by the
package (optional or not), it's almost certainly a dependency.

[Dima Pasechnik]

as Debian does not have iconv in libgd, I assume it's safe to remove
the dependence.
We should get an spkg-configure.m4 for libgd, it's really silly to
build it everywhere...
(I guess that's what Michael is working on :-))

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/5CD976F5.30203%40UGent.be.

[Jeroen Demeyer]

On 2019-05-13 16:04, Dima Pasechnik wrote:
> as Debian does not have iconv in libgd, I assume it's safe to remove
> the dependence.

If that's possible, sure.

[E. Madison Bray]

On Mon, May 13, 2019 at 3:53 PM Dima Pasechnik <dim...@gmail.com> wrote:
>
> iconv is only installed on Cygwin anyway (apart from surely dead HP
> port, and fallen behind Solaris port,
> which probably no longer needs it anyway).
> So this is a red herring one way or another.

Wow, I haven't worried too much about iconv up to this point as it's a
rather small library and quick to build.

But indeed it's only even installed on Cygwin, HP-UX, and Solaris.
And I strongly doubt it's needed for Cygwin anymore (if it ever was).
Iconv comes standard in Cygwin installations, and the version is
likely quite a bit more recent than 9 years ago when it was first
added as a package for Sage.

I'll also see about adding an spkg-configure.m4 for iconv. We can
keep the package for now for HP-UX and Solaris in case anyone wants to
pick up work on those ports again.

As for removing it from the list of dependencies for libgd I'm not
sure enough to give a confident answer.

[Michael Orlitzky]

On 5/13/19 10:04 AM, Dima Pasechnik wrote:
>
> We should get an spkg-configure.m4 for libgd, it's really silly to
> build it everywhere...
> (I guess that's what Michael is working on :-))
>

I looked at libgd and saw that we have in-progress tickets for its other
two dependencies, freetype and libpng, but not for iconv. So I began
looking at iconv, which is going to be a pain in the ass, because there
are a few different implementations that need to be detected in
different ways. For example, we probably have to reproduce all of R's
iconv feature detection to ensure that we get a satisfactory copy.

As a lazy person, that immediately lead me to ask the question: could I
just... ignore iconv... and work on libgd anyway? The iconv detection in
libgd is automagic, so we would have to force-disable the iconv support
somehow, but I don't think libgd would be any worse for it.

[Dima Pasechnik]

I certainly would try just going for a iconv-less system libgd support
and see if it works.
Libgd is only used in sagelib...

>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/164f81c6-87e3-67c9-1d3a-b3b146b5da11%40orlitzky.com.

[E. Madison Bray]

On Mon, May 13, 2019 at 5:43 PM Michael Orlitzky <mic...@orlitzky.com> wrote:
>
> On 5/13/19 10:04 AM, Dima Pasechnik wrote:
> >
> > We should get an spkg-configure.m4 for libgd, it's really silly to
> > build it everywhere...
> > (I guess that's what Michael is working on :-))
> >
>
> I looked at libgd and saw that we have in-progress tickets for its other
> two dependencies, freetype and libpng, but not for iconv. So I began
> looking at iconv, which is going to be a pain in the ass, because there
> are a few different implementations that need to be detected in
> different ways. For example, we probably have to reproduce all of R's
> iconv feature detection to ensure that we get a satisfactory copy.

Hmm, thank you for pointing that out. It doesn't look too bad and not
*all* of it needs to be reproduced, but some of it yes.

The tricky thing about iconv is that sometimes it's built into libc
and sometimes it's a separate library that needs to be linked with
-liconv. And furthermore, (especially in the former case) sometimes
iconv is a macro, and sometimes it's a function.

There's actually a standard AM_ICONV that apparently handles all these
cases: https://www.gnu.org/software/gettext/manual/html_node/AM_005fICONV.html
In fact, looking at the /usr/share/aclocal/iconv.m4 on my system, it
looks like R borrowed its check from this.

The other thing R checks which is more specific to R is that it
requires iconv to support (as most any will these days) UTF-8, ASCII,
latin-1, and UCS-* encodings. I think we could probably safely just
assume that for any platforms Sage supports, but if you want to be
extra sure I could easily replicate that check as well.

> As a lazy person, that immediately lead me to ask the question: could I
> just... ignore iconv... and work on libgd anyway? The iconv detection in
> libgd is automagic, so we would have to force-disable the iconv support
> somehow, but I don't think libgd would be any worse for it.

Sure! As far as implementing an spkg-configure.m4, at least initially,
it doesn't look like there needs to be a deep interaction here. If we
do find something later we can add it on.