Re: LTLIBICONV / LIBICONV question

[Tim Rühsen]

On Tuesday 14 June 2016 14:24:18 Mike Frysinger wrote:
> On 14 Jun 2016 17:02, Tim Ruehsen wrote:
> > On Tuesday 14 June 2016 10:20:59 Mike Frysinger wrote:
> > > On 14 Jun 2016 15:21, Tim Ruehsen wrote:
> > > > for GNU Wget we don't (explicitely) use libtool, but on some systems
> > > > LTLIBICONV is set while LIBICONV is not.
> > > > See http://savannah.gnu.org/bugs/?48193 for details.
> > > > 
> > > > But I also remember seeing LIBICONV set and LTLIBICONV unset in the
> > > > past.
> > > > 
> > > > At this point, we are looking for clarification about what to put into
> > > > Makefile.am / LDADD. Currently (since a few days) we have
> > > > 
> > > > LDADD = $(LIBOBJS) ../lib/libgnu.a $(GETADDRINFO_LIB) $(HOSTENT_LIB)
> > > > $(INET_NTOP_LIB) $(LIBSOCKET)\
> > > > 
> > > >  $(LIB_CLOCK_GETTIME) $(LIB_CRYPTO) $(LIB_SELECT) $(LTLIBICONV)
> > > >  $(LTLIBINTL) $(LTLIBTHREAD)\
> > > >  $(SERVENT_LIB)
> > > > 
> > > > In the past we used $(LIBICONV) and not $(LTLIBICONV).
> > > > 
> > > > What is correct ?
> > > > Should we perhaps add both $(LIBICONV) and $(LTLIBICONV) to LDADD ?
> > > 
> > > the gettext manual describes both variables:
> > >   
https://www.gnu.org/software/gettext/manual/html_node/AM_005fICONV.html
> > > 
> > > you should follow those guidelines and not pay attention to the values
> > > each one is set to.
> > 
> > I am aware of this part of the docs. I doesn't answer my questions above,
> > thus leaves me a bit clueless.
> 
> if you're using libtool, then use $(LTLIBICONV).  if you aren't using
> libtool, then use $(LIBICONV).
> 
> maybe i'm missing something obvious in your question though ?

Yes, your are missing the first sentence:
> for GNU Wget we don't (explicitely) use libtool, but on some systems
> LTLIBICONV is set while LIBICONV is not.

In other words: We are not using LT_INIT nor A[CM]_PROG_LIBTOOL in 
configure.ac. So, I would say that we don't use libtool.

But then, LTLIBICONV is set correctly on some systems... here I start to 
repeat myself, please continue reading above ;-)

It is not clear to any of us why we should use LTLIBICONV instead of LIBICONV 
- btw, we used LIBICONV for many years without issues and now someone 
complained. And as it turned out, suddenly LTLIBICONV seems to be correct.

The docs doesn't help us, the bootstrap output doesn't help either:
"$(LTLIBICONV) when linking with libtool, $(LIBICONV) otherwise"

I intuitively would say, we could use both. In the worst case, we have
2x -liconv on the linker command line. Can't be so bad !? WDYT ?

Regards, Tim

signature.asc
Description: This is a digitally signed message part.