On 08/28/2013 02:34 AM, Boaz Harrosh wrote:
On 08/28/2013 07:59 AM, ronnie sahlberg wrote:
On Tue, Aug 27, 2013 at 3:56 PM, Andy Grover <agrover@xxxxxxxxxx> wrote:
I think you may be able to avoid making bs.c into a shared library if you
link tgtd with the -E linker option.
Personally I prefer the .so option:
For one I hate any double dependency, and specially an executable dependency.
This is bad code design and a call for tons of problems. It is called the
libraries hell. Each module should be self contained or only depend downwards
on lower stack. library rules are exactly like package rules only depend
downwards, and the complex dependency should be a tree never a graph ...
Second with the bs.c as library it is clear and protected what are the API's
the backends are to depend on and import, No crazy unexpected stuff from
a loaded plugin.
Please keep the second version as you sent it it is a much better style
than the -E hack.
You only get library hell when there are binary modules that expect to
run across different versions of the executable. I don't think that's
what we're talking about here. My initial request was to make it
possible for users to avoid installing dependencies for parts of tgt
they won't be using. That just requires tgtd and bs_rbd.so be separate
binaries, and tgtd work in the the absence of bs_rbd. Both binaries
would always still be generated from the same source version.
So for me, linking tgtd with -E seems like the simplest solution to
reach that modest goal, but I'm fine with whatever Ronnie and Tomo do,
as long as it does the basic thing :-)
> Also in porting to other platforms the executable exporting symbols is
> not available on all platforms.
Do you have more info? 'ld' manpage didn't mention any platform issues.
Regards -- Andy
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
