[Gnucash-changes] check_data_type, backend configuration and gettext

Neil Williams linux at codehelp.co.uk
Tue Sep 6 06:44:27 EDT 2005


On Monday 05 September 2005 3:28 pm, Derek Atkins wrote:
> Umm, I don't think you can necessarily guarantee that the .la is
> installed.

? I thought it was the recommended method for GNU systems ?

http://www.gnu.org/software/libtool/manual.html#Finding-the-dlname

> Indeed, most places do NOT install the .la, just the .so 
> (or .dynlib) in the packaging system.

Is there a problem in requiring that it *is* installed? All packaging systems 
that I know will *allow* it to be installed, it may not be common practice 
but it can be done - why else would GNU recommend it? 

Isn't this a case of the packaging dictating to the source? If there is a 
standard and recommended GNU method that is declared as "[t]he most 
straightforward and flexible implementation" why should the source be forced 
to support a less straightforward and less flexible method?

What if a new system starts supporting GNU libtool and adds yet another suffix 
to the possible list?

You've asked me to put the demands of the source above those of the packaging 
and now I'm confused.
:-(

> Also, I'm not sure I like the new API, unless "directory" is a "hint"
> -- the ldopen() should have a set of directories it can search.  A
> "search path".

I'll double-check, I thought it did this already (internally). If not, I'll 
add it - as recommended on the libtool page above.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050906/2b84825a/attachment.bin


More information about the gnucash-devel mailing list