Hello Vitaly,

I hope this gets to you, and sorry for taking so long to answer it. It
seems to have been buried in my inbox.

Anyway, these "underlinkages" as you call them are in fact designed that way,
because the symbols are resolved at runtime, which is one of the advantages
of having shared objects.  They do not create any problem when Bacula is
properly installed with all the components and all the needed libraries, thus
there is really no need to change anything.

To answer your last question: it is in a sense an architectural consequence rather
than a decision, and they all represent entry points or external symbols that are
implemented today, so there is nothing to work on.  They are simply dependencies
between the different shared objects and the "core" code.

Best regards,

On 11/29/2011 03:13 PM, Vitaly Kuznetsov wrote:

there are several underlinkage problems within bacula libraries. These problems are not functional problems, having underlinked libraries is just not clean. I tried to fix some issues in two attached trivial patches (made over Release-5.2.2 commit):
Link libbaccfg and libbacpy against libbac
Link libbaccats-mysql, libbaccats-postgresql, libbaccats-sqlite3 against libbac and libbacsql

There are some problems remaining:
libbacsql-5.2.2.so: undefined symbol: db_init_database (exists in libbaccats-mysql, libbaccats-postgresql, libbaccats-sqlite3)
libbaccfg-5.2.2.so: undefined symbols: r_first, resources, r_last, res_head, res_all, dump_resource, save_resource, free_resource (exist in console, dird, filed and stored binaries)
It's also not very neat, but fixing them is not so trivial. Are there any architectural decisions that are not implemented right now? Maybe I could try working on it.

All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.

Bacula-devel mailing list