.la's are a programmer's nightmare. IMHO they cause more problems than they solve. I don't care what GNU says -- the world is not GNU. There are other systems out there.
If there's a new platform out there that has a new form of dynamic library I suspect that we'll have other problems than just the name of the dynamic library extension that would require source changes. E.g. Windows. Right now there ARE only two.. .so and .dynlib .. Eventually there may be a third, .dll. Not too many to keep track of ourselves, IMHO. And this way we can work around the .la brokenness. The real lesson here: Don't believe everything you read from GNU. -derek Neil Williams <[EMAIL PROTECTED]> writes: > 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/ > > _______________________________________________ > gnucash-devel mailing list > [email protected] > https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH [EMAIL PROTECTED] PGP key available _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
