Bug 476954

Summary:	[science overlay] dev-lang/julia and [main tree] dev-libs/skalibs- file collision in librandom.so
Product:	Gentoo Linux	Reporter:	James Cloos <cloos>
Component:	Current packages	Assignee:	Michael Weber (RETIRED) <xmw>
Status:	RESOLVED OBSOLETE
Severity:	normal	CC:	sci
Priority:	Normal
Version:	unspecified
Hardware:	All
OS:	Linux
Whiteboard:
Package list:		Runtime testing required:	---

Description James Cloos 2013-07-15 17:53:12 UTC

Both packages install a librandom.so and env.d file with an LDPATH entry.

In skalibs’ case, librandom.so is a symlink to a versioned file.

In julia’s case, there is no versioned file.

Because skalibs’ env.d file has higher priority, julia is unusable if skalibs is installed.

Skalibs wasn’t in my world, so it must have been a dependency, though I haven’t found which package depends on it....  (Nothing in /var/db/pkg or /usr/portage/metadata/md5-cache mention it.)

Comment 1 James Cloos 2013-07-16 11:51:14 UTC

This is not a file collision.  The change to the description is wrong.

And only julia is in the overlay.

The two librandom.so files are in different directories.  Both packages rely on having those directories in LDPATH.  The dynamic loader will only ever find the one in the higher-priority LDPATH entry.

Comment 2 Michael Weber (RETIRED) gentoo-dev

2013-07-16 12:10:08 UTC

I agree that the library name is super vague.

And as it's no file collision in the system, detected by portage, it's even worse.

Adding a blocker is kinda out of scope; julia ist just in a overlay, but it's science ovelray.

Any suggestion on how to proceed?

Comment 3 Justin Lecher (RETIRED) gentoo-dev

2013-07-16 12:13:18 UTC

(In reply to Michael Weber from comment #2)
> Any suggestion on how to proceed?

Using rpath during linking?

Comment 4 Arfrever Frehtes Taifersar Arahesis 2013-07-16 12:14:41 UTC

I suggest to rename libraries of both packages:
libjulia_random.so
libskalibs_random.so

(E.g. dev-libs/boost provides libboost_random.so library.)

Comment 5 James Cloos 2013-07-17 09:32:58 UTC

It is possible julia will rename its librandom.so upstream.

On rpath, the ebuild sed(1)s RPATH to RPATH_ORIGIN in the makefile.  I suspect due to the fact that upstream may have used /usr/lib/julia, whereas the ebuild installs the libraries in /usr/$(get_libdir)/julia.

But current upstream does this:

  RPATH = -Wl,-rpath,'$$ORIGIN/../$(JL_PRIVATE_LIBDIR)' -Wl,-rpath,'$$ORIGIN/../$(JL_LIBDIR)' -Wl,-z,origin
  RPATH_ORIGIN = -Wl,-rpath,'$$ORIGIN' -Wl,-z,origin

Later on, iff sci-libs/mkl is used, upstream adds:

    RPATH_MKL = -Wl,-rpath,$(MKLLIB)
    RPATH     += $(RPATH_MKL)
    MKL_LDFLAGS += $(RPATH_MKL)

Instead, the ebuild could use sed(1) to change:

JL_PRIVATE_LIBDIR = lib/julia
JL_LIBDIR = lib

to replace lib with the output of $(get_libdir).

Perhaps that would avoid any need to add /usr/$(get_libdir)/julia to LDPATH?

Comment 6 Mira Ressel 2016-03-24 19:37:57 UTC

Current dev-libs/skalibs versions don't install a librandom.so anymore, so this bug can be closed.