Re: [RFCv2 00/15] RFCv2: Consolidated userspace RDMA library repo

[Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>]

On Fri, Aug 26, 2016 at 11:00:22PM -0400, Doug Ledford wrote:

> The most recent upstream libibverbs includes -fno-strict-aliasing
> now so it can be dropped from the extra stuff in the Fedora spec
> file.

Looking at strict-aliasing is the last build issue, I'd like to
minimize the places we turn it on, so if we have been shipping
libraries that never needed it I don't want to blanket enable
it. Ideally we could run with -fstrict-aliasing, but I realize how
hard that can be..

Do you know there are confirmed bugs without -fno-strict-aliasing?

> 2) Static libraries. Do we want to continue to provide these?

> I'm ready to drop static libraries.

Great.

> > 3) Version numbers. What version numbers do we give to the sub
> >    packages? I guess this is very distro specific.
>
> You can not give different versions to sub-packages.  Or, allow me to be
> more precise:  You can't use the Version: tag on sub-packages, it
> resets

Okay, I should also clarify that when putting this all together I need
to consider Debian as well. I'm happy if RH wants to just use a jumbo
RPM, but that doesn't match Debian Policy regarding shared libraries
[my suggestions were informed by Debian Policy].

So I may look at deb packaging to guide the cmake install components
then, and try and get someone from the Debian community involved. I
started with RPM because that seems to be what most of our developers
use.

> >    I don't want to dictate what distros should do, but this is best
> >    done with support from the build system upstream, so some guidance
> >    on what to do is needed to finish the cmake stuff. (see #6)
> 
> I'm inclined to wrap it all up into a single package. librdmacm,
> libibcm, libibumad, libibverbs, providers, all of it.

Okay, so just simple rdma-libs, rdma-utils, rdma-libs-devel works for
you? Nothing more to do then.

> I would also be inclined to contribute the rdma scripts we have as
> part of the package too.  I think some of them can use some cleanups
> if they are going to become an upstream item instead of a RH
> specific item, but otherwise they work well.  If I did that, I would
> also welcome appropriate similar scripts for OSes that use different
> tools than RH OSes.

This sounds like a good idea.

>> 5) Valgrind - I've noticed CentOS forces valgrind on, and Debian
> Agree.  Changing the default on this when present is good.

Will do.

> > 7) NDEBUG - As upstream do we want this set or left unset for a
> >    release build. It eliminates all asserts and a few other things.
> >    I'm not sure what is being done today, but the %cmake rpmbuild
> >    default forces it on. (IMHO, upstream should decide this, not
> >    downstream?)
> 
> I think I would set this.  But I'm flexible.  Basically, I know end
> users want Valgrind.  We've had multiple requests to enable it.
> They

Okay, any thoughts on when assert should be enabled then? It is
useless to code it if we just compile it out in all builds.

Maybe non-packaging builds can default to leave assert in or
something?

> > 9) libtool .la files. I preserved them, but if distros don't want them
> >    I'd love to ditch them.
> 
> Drop them.

Yay, I think debian agrees.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html