Linking the shared library FOO.la against the loadable module
warlord at MIT.EDU
Tue Sep 6 16:37:33 EDT 2005
Quoting Neil Williams <linux at codehelp.co.uk>:
> On Tuesday 06 September 2005 7:00 pm, Derek Atkins wrote:
>> Yea, GnuCash's previous developers wanted gnucash to be a bunch of Loadable
>> Modules.. But they never finished the modularlization, and they didn't
>> understand the difference between a Shared Library and a Loadable Module.
> Is that just a Mac OSX thing or is that difference important for GNU/Linux
> i.e. When I eventually get CVS G2 to compile on OSX without -module,
> would the
> linux tree build with the same change?
Honestly I don't know. I know it's an important condition on some
don't know which ones.
>> It's part of the brokenness of the current gnucash module architecture.
>> There is no simple fix. It's unclear whether just removing the -module
>> will actually
>> solve the problem. It may be a short-term fix...
> Are we talking of different problems here - the limited problem of a CVS Mac
> OSX build does look like it will be solved by removing the -module LDFLAG.
No, it's the same problem. Just putting a different spin on it.
> I also appear to have solved the GTKHTML problems of earlier (principally by
> removing an old 1.8 package - so the environment variable hack was a waste of
Sorry, which gtkthml problems?
> I appreciate removing the flag won't undo the work that required the flag to
> be set, but will it break the build or break the application?
I dont know... It will probably not break the build. It may break the
application on some platforms, but I don't know for sure.
> The important thing is that if this is ever committed, everyone needs to do a
> make clean, not just a make or even ./autogen.sh && make. It is limited to
> the directories involved but I've found another half dozen or so later in the
> build that would also need a make clean.
Eh, that's the easy part.
>> In the end, we really need to rethink the modularization effort, and how we
>> build our application. What parts REALLY need to be modules, and how do
>> they link against the core code?
> I can help as far as I can - but that's only the non-GUI stuff as it relates
> to ancillary logic, objects, backends and CashUtil.
> So that would make:
> libqof1, libcashobjects.la, libgnc-backend-file.la, libcashlogic.la (a new
> That would replace the entire contents of:
> and various, as yet undetermined, sections of the GUI code into a
> shared logic
> library (shared between GnuCash-GUI and CashUtil).
PLEASE PLEASE PLEASE PLEASE PLEASE keep src/business SEPARATE. DO NOT require
src/business to get integrated into src/engine. It's a separate set of
for a REASON. Please keep it that way. GnuCash (and Cashutil) should work
just fine WITHOUT the business objects loaded.
> Well, the build gets a LOT further than ever before now. I'm getting some
> different linker errors about multiple definitions which could again be down
> to spurious packages.
Or it could be the -module vs. non .....
> One down, don't know how many more to go but I'll keep on at it.
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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel