Re: [PATCH 0/8] Improve build process

On Thu, Feb 12, 2015 at 09:17:39AM +0000, Gonzalez Monroy, Sergio wrote:

On 12/02/2015 05:41, Neil Horman wrote:

quoted

On Wed, Feb 11, 2015 at 11:11:13AM +0000, Gonzalez Monroy, Sergio wrote:

quoted

quoted

From: Neil Horman [mailto:nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org]
Sent: Friday, January 30, 2015 6:13 PM
To: Gonzalez Monroy, Sergio
Cc: Thomas Monjalon; dev-VfR2kkLFssw@public.gmane.org
Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process

On Fri, Jan 30, 2015 at 05:38:49PM +0000, Gonzalez Monroy, Sergio wrote:

[snip]

quoted

quoted

So would it be reasonable to add DT_NEEDED entries to all DPDK libraries

but EAL?

quoted

If I understood what you were saying right, we could enforce the
'dependency' in the linker script with something like this:
$ cat  librte_eal.so
INPUT( librte_eal.so.1 -lrte_mempool -lrte_malloc) We could have such
linker script for librte_eal.so instead of the soft link once
versioning is in place.

Correct.

quoted

Things that would be missing versus the proposed patch:
 - As I have mention in previous post, ldd info for EAL library would not

reflect

quoted

   its dependency to other DPDK libs.

librte_eal.so would no show those dependencies, as far as I know (though I
haven't explicitly checked).  The subordunate libraries included in the input
line, may or may not show dependencies among themselves, depending on
your build setup (and the use of --no-as-needed and -l when linking the
individual .so libraries.

quoted

 - I was enforcing resolving all references when building the libraries (-z

defs), so

quoted

   we either remove it altogether or skip eal.

I think thats correct, yes.

quoted

 - All apps would show DT_NEEDED entries for a set of DPDK libraries that
   in most cases are required (eal, mempool, malloc, mbuf, ring VS
dpdk_core)

I think apps linked to libdpdk_core would have DT_NEEDED entries for
libdpdk_core, not the subordonate libraries (though check me on that to be
sure).

Just checked on this and they do link against the subordinate libraries, although
It does not really matter as we are dropping the 'core' library approach anyway.

ok, understood.

quoted

quoted

quoted

I think that the linker script approach is reasonable if we prefer to
go that way instead of creating a core library.

I think it would make sense from a build environment point of view, in that it
allows library specific flags to be incorporated properly.  I think the only
downside is that the individual libraries still need to be carried around
(though they can be ignored from an application build/run standpoint).
You're question should probably be asked of people using COMBINED_LIBS
currently to make sure that meets their needs, though I think it will.

Neil

So I just realized that I was not having into account a possible scenario, where
we have an app built with static dpdk libs then loading a dso with -d  option.

This is very true, but I was under the impression that the only things that were
dlopen-able were PMD's, which would not be part of the core library.  Was I
mistaken?

As far as I know you are right that only PMDs are being dlopen.
The proposed patch though, added DT_NEEDED entries for PMDs too, so they
would need to be
left empty for them to work in such scenario.

Is that reasonable?

Ah, I see now.  What you're saying is that, in our proposed scenario, a PMD that
requires, say librte_ether, will have a DT_NEEDED entry explicitly for that
library, as opposed to libdpdk_core, is that correct?  If it is, I think thats
ok.  We will still need to have the librte_ether library around, because the
libdpdk_core DSO will reference it on its INPUT line, and in fact it should
already be loaded because of that, rendering the DT_NEEDED entry moot.  That is
to say, and requirements from a PMD codified in a DT_NEEDED entry should already
be satisfied by the application if it properly linked against libdpdk_core.

That said, it should also be safe to remove the DT_NEEDED entry from the PMD for
the same reason (the fact that any dependent libraries should already be loaded
makes it non-useful).

I would personally just leave them in place, as they are harmless, and doing so
is really just more work, but if you want to remove the DT_NEEDED's from the
PMD's it won't hurt anything

Or is there another facet to this that I'm missing?

Best
Neil

Regards,
Sergio

quoted

quoted

In such case, because the pmd would have DT_NEEDED entries, dlopen will fail.
So to enable such scenario we would need to build PMDs without DT_NEEDED
entries.

Thoughts?

As I mentioned above I thought the only thing that would typically be referenced
via dlopen would be libraries that were not part of the unified core library.
if thats not the case, then yes, we need a little more thought here
Neil

quoted

Regards,
Sergio