Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 476954 - [science overlay] dev-lang/julia and [main tree] dev-libs/skalibs- file collision in librandom.so
Summary: [science overlay] dev-lang/julia and [main tree] dev-libs/skalibs- file colli...
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Michael Weber (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-15 17:53 UTC by James Cloos
Modified: 2016-03-24 19:37 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.