Linking the shared library FOO.la against the loadable module

[Derek Atkins]

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
> too?
>
> 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 
platforms.  I
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
> effort!)
> :-(

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
> one).
> That would replace the entire contents of:
> src/engine/
> src/backend/file/
> src/business/business-core/
>
> 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 
modules
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
-- 
       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