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/
pgpm1XkOieji3.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
