On Tuesday 06 September 2005 2:38 pm, Derek Atkins wrote: > .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.
Oh, come on, Derek! I wrote to you about this in August, specifically mentioning the change from using the .so to the .la and you didn't mention then it was a bad idea to use the .la! You sounded encouraging and happy that I'd got it working: Sun, 21 Aug 2005 09:01:31 -0400 > > I've now got the gnc-backend-file library to open using the dlopen() > > routines > > and I've implemented a platform-independent way of accessing those > > libraries > > to replace Linus' direct call to the .so. I'm using the .la to provide the > > name of the shared library - .so on GNU/Linux, .dylib on OSX - and only > > this > > morning I successfully loaded the gnc backend in CashUtil using this > > method. > > > nice!!! Did you miss my comment about using the .la or is there some other problem? I've mentioned the use of the .la in lots of emails since. Each time I've referred to the new library build layout on this list I've used the .la: libcashobjects.la and libgnc-backend-file.la. Why the change now? > Right now there ARE only two.. .so and .dynlib .dylib (no 'n') > .. 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. So where now? Do you want me to: 1. implement some completely new method of determining the library name from configure via $host? 2. use the .la - as now or 3. abandon the lot for a list of static const char* (which is what we had in the first place)? I'm horribly confused. Or do you want: 4. Some combination of two/three of the above? Using one and falling back to the old static char* method? > The real lesson here: Don't believe everything you read from GNU. Which systems, specifically, don't install .la files and would *not* allow us to do so? These aren't someone else's .la files - these are created from GnuCash source and installed using GnuCash Makefiles. Can't we simply specify that these ARE needed for GnuCash? They are simple text files as far as the installation process is concerned. I'd then do the same for QOF. I'm constantly being battered with the libtool manual from other sources - it's a recommended method in the libtool manual and I simply cannot understand the sudden change of heart. How can I know which bits of the standards, which bits of the manuals, I can actually believe and use? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
pgpO7M1jKUeMd.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
