backend configuration and gettext
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
? I thought it was the recommended method for GNU systems ?
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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