Re: [SPDK] Howto build with an external env, i.e. alternate CONFIG_ENV

[Walker, Benjamin <benjamin.walker at intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Hi Lance,

On Fri, 2018-07-20 at 16:34 -0500, Lance Hartmann ORACLE wrote:
> Another especially notable take-away for me was the realization that the
> environment library -- I'll refer to the default env for example here,
> libspdk_env_dpdk.a -- consists only of the objects compiled from
> SPDK_ROOT_DIR/lib/env_dpdk.   With the ability to specify an alternate
> environment, semantically, I had mistakenly assumed that the env library would
> contain not only the SPDK implementation of the environment API, but also
> everything on which it depended; i.e. for the default environment, the DPDK
> objects.   But, that doesn't appear to be so.   Instead, when performing final
> linking of each SPDK executable, not only is the SPDK environment library
> specified, but so are the necessary DPDK libs on which it depends.   Variables
> pulled in from the SPDK's environment makefile, env.mk, are used to specify
> those DPDK libs along with additional, special linking flags.
> 
> We need to update the doc's Porting Guide to reflect these details, and I'd be
> happy to volunteer to work on that effort. 

Please do!

> However, before embarking on that task, I'd like to pose the question:   are
> there reasons why we couldn't or shouldn't produce the environment library to
> consist of both the SPDK env implementation layer and the objects on which it
> depends?  It would seem that would make final linking of executables a little
> easier and reduce the complexity/effort of someone wanting to develop and use
> an alternate environment.

How do you envision this playing with environment libraries that need to link
against shared libraries, especially ones provided with the system itself? I'm
not an expert in all of the available linker options, so maybe there is some way
to embed enough information to properly link/load a shared library directly into
the static library.

Thanks,
Ben