prefer in-tree libiconv over the system libiconv?

prefer in-tree libiconv over the system libiconv?

[Joel Brobecker]

Hello everyone,

Tom and I were discussing about libiconv today: The idea is that,
if you put the libiconv sources in the root directory of the GDB
sources, configure will automatically pick it up and build GDB
with this libiconv. However, the current setup is such that, if
we find a system libiconv that provides the functionality we need,
then the system libiconv is going to be used instead.

This means that placing the libiconv sources in the GDB sources
is not enough to make sure that GDB gets built with that libiconv.

On the one hand, this is convenient if you just want GDB to be built
without having to worry whether libiconv is available on the host
or not.

But, on the other hand, for a distributer like AdaCore (and maybe CS),
it makes it harder to make sure which libiconv gets linked in.
I suggest we change the logic a bit so that, if the libiconv sources
are in-tree, then use this libiconv over the system one.  The
alternative is to have a configure switch that would allow us to
specify the location of the libiconv install from the in-tree build.

Thoughts?

-- 
Joel

Re: prefer in-tree libiconv over the system libiconv?

[Tom Tromey]

Joel> But, on the other hand, for a distributer like AdaCore (and maybe CS),
Joel> it makes it harder to make sure which libiconv gets linked in.
Joel> I suggest we change the logic a bit so that, if the libiconv sources
Joel> are in-tree, then use this libiconv over the system one.  The
Joel> alternative is to have a configure switch that would allow us to
Joel> specify the location of the libiconv install from the in-tree build.

Joel> Thoughts?

I think the relevant scenario is something like the old Cygnus "devo"
tree, where you would have libiconv always present and also use the
single soruce tree on all hosts.  In this situation, would you prefer
to pick up the system iconv on Linux?  Or would you prefer to always
use libiconv and have identical behavior across hosts (at some cost; I
think the native glibc iconv probably handles more charsets).

I guess specifying the libiconv prefix in the build tree might work.
Something like --with-build-libiconv or --with-system-iconv would be
simpler and less error-prone, though.

Anyway, I'm happy to implement whatever approach you want here, just
let me know.

Tom

Re: prefer in-tree libiconv over the system libiconv?

[Joel Brobecker]

> I think the relevant scenario is something like the old Cygnus "devo"
> tree, where you would have libiconv always present and also use the
> single soruce tree on all hosts.  In this situation, would you prefer
> to pick up the system iconv on Linux?  Or would you prefer to always
> use libiconv and have identical behavior across hosts (at some cost; I
> think the native glibc iconv probably handles more charsets).

My very personal preference is to go for consistency. I like to know
that the library will behave the same from HP/UX to GNU/Linux.
Also, I don't like depending on system libraries, because I lose a bit
of control over what the user ends up using. I am afraid of situations
where we cannot reproduce and identify a bug simply because the user
has a different version of the library from the version that I have.

I think that the current approach would have made more sense if libiconv
was in fact made part of the GDB sources, thus forcing people to have
the libiconv sources be part of their tree.

That being said, now wearing my AdaCore hat, I'm perfectly happy to have
to use a command-line switch. We already do that with libexpat, and
it's done in a script anyway...

I'm actually happy to work on a patch once others have had a chance
to tell us what they would prefer. If no one speaks up, then I guess
I'll implement what my prefered alternative (this is my way of
threatening everyone into participating ;-).

-- 
Joel