libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: rewrite try_dlopen (2)


From: Gary V. Vaughan
Subject: Re: rewrite try_dlopen (2)
Date: Wed, 06 Oct 2004 16:52:56 +0100
User-agent: Mozilla Thunderbird 0.8 (X11/20040913)

Hi Bob, Ralf!

Bob Friesenhahn wrote:
> On Wed, 6 Oct 2004, Ralf Wildenhues wrote:
> 
>> I did a tiny bit of research:  This TODO entry is from 1999.  Haven't
>> found mailing list archives from that time, but I strongly suspect that
>> the aim was not use within a signal handler, but use of ltdl in an
>> embedded environment which lacks full libc support.
>>
>> At that time, I think it would have made sense, too, since there was
>> less support for open embedded environments then and libraries like
>> newlib did not provide stdio.  Now users have several small libc
>> packages to choose from (e.g., newlib, dietlibc, uclibc etc), and what's
>> more, these now all support stdio to some extent.
>>
>> So in light of that, should we just ditch this TODO item?
> 
> Without continued demand we should ditch it.  I haven't noticed any
> continuing demand.

Agreed.

>> Additionally, should then get_line() be getline() and LIBOBJed in the
>> same manner as argz.c?
> 
> Gary is best to answer that.

Yes please.  We should coordinate this with the gnulib folks
<address@hidden> who have a blessed (and debugged) getline.c that
we might be able to use.  They are currently in the process of splitting
the code into LGPL and GPL though, so it may be that their getline.c is
GPL (or relies on another gnulib module that is GPL).  That would have
some implications:

  (i) libltdl is LGPL, and couldn't use a GPL gnulib getline.c
 (ii) gnulib may be interested in accepting an LGPL getline.c

Note that I contributed the argz stuff to gnulib, hence the funny extra
lines in the header, and the effort to make sure it is self contained.
In case of (ii) above we can do something similar with your renamed
getline function.

>> Slightly independent of this subject, would it be ok for you if ltdl
>> avoided *printf() and *scanf()?  Besides a potential efficiency issue,
>> they cause a quite noticeable increase in the size of a static binary
>> that uses ltdl but not those functions.
> 
> Most applications/libraries of any significiant size and which use
> libltdl will already depend on printf()/scanf() in one way or another so
> the penalty has already been paid.  I wouldn't worry terribly much about
> minimum static application size.  The *printf() and *scanf() functions
> often introduce security concerns so if you can reasonably do without
> them then don't use them.

Agreed on all counts.

[[mmap discussion snipped]]

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]