On Wed, Feb 08, 2017 at 08:37:58AM +0200, Leon Romanovsky wrote:
> On Tue, Feb 07, 2017 at 01:59:30PM -0700, Jason Gunthorpe wrote:
> > On Tue, Feb 07, 2017 at 10:14:28PM +0200, Leon Romanovsky wrote:
> >
> > > > > Compile the library to build/lib/libibverbs-dv-mlx5.so.1.0.13
> > > > > and setup a symlink build/lib/libmlx5-rdmav2.so -> libibverbs-dv-mlx5.so.1.0.13
> > > >
> > > > Just as a note, I'm calling it libmlx5 and not libibverbs-dv-mlx5.
> >
> > That will clash with the legacy providers, don't recommend it.
>
> Is it real scenario? Will these legacy providers co-exists with
> rdma-core library? I really don't like libibverbs-dv-mlx5 name, it is
> too long and have feature name in the name.
I'd save having the 'dv' in the name is sort of the point...
The possible issue would be if an app links to this new library and is
run on an old system with the old type of library - then you'd get a
really ugly linker error message. It is best to avoid re using library
names.
That said, the old name is libmlx4-rdmav2.so so it should be OK..
> > execute_process(COMMAND "${CMAKE_COMMAND}" -E create_symlink
> > "lib${DEST}.so.${VERSION}"
> > "${BUILD_LIB}/lib${DEST}-rdmav2.so")
> >
> > It creates a dangling link until compilation, which is fine..
>
> In non-ninja builds, it doesn't create libmlx5-rdmav2.so symlink in
> build/lib, because libmlx5.so is not created yet. This is why I ended
> with custom target.
Eh? That doesn't sound right.
> > > install(FILES "${BUILD_LIB}/lib${DEST}-rdmav2.so" DESTINATION "${CMAKE_INSTALL_LIBDIR}")
> >
> > This line isn't needed, it is part of the next function
>
> Not for build/lib
>
? Do not install something calleld lib*-rdmav2.so to /usr/lib/
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
