Add %LIBRARY_BIN% to PATH on windows

[ddale]

Some anaconda windows packages, for example zlib and libpng, install dlls in %PREFIX%\Library\bin. This directory must be included on the %PATH%, or Windows will be unable to load the dlls. However, the [ana|mini]conda installers do not add this directory to the %PATH%, nor does the activate command.

[asmeurer]

I think there is a more general problem here of how to make DLLs available on Windows. For instance, with my R package, we would have to have it's directory on the PATH as well, I think.

[ddale]

Agreed, but is there any chance for a near term fix for the packages
already provided by anaconda?

On 5:51pm, Fri, Dec 19, 2014 Aaron Meurer notifications@github.com wrote:

I think there is a more general problem here of how to make DLLs available
on Windows. For instance, with my R package, we would have to have it's
directory on the PATH as well, I think.

—
Reply to this email directly or view it on GitHub
#233 (comment)
.

[tswicegood]

@ddale let me make sure I understand correctly: to get the DLLs to be picked up properly by Miniconda, not only do we need the actual bin directory (at least as its referred to in the posix world), but also the Library\bin directory where DLLs get dropped. So we need the equivalent of (adjusted, obviously for Windows):

export PATH=${PREFIX}/bin:${PREFIX}/Library/bin:$PATH

If we adjusted that for how you set variables and reference variables in Windows, we would have all of the DLLS picked up correctly?

[ddale]

@tswicegood Yes, your explanation is commensurate with what I observed for trying to link to DLLs installed in Library\bin on windows (tested by adding/removing this path from my PATH globally).

However, @ilanschnell explained that packages installing under Library are only meant to be statically linked. The documentation at http://conda.pydata.org/docs/build.html is a little vague here, stating that packages will "usually" statically link such support packages, and since libpng and zlib conda packages actually provide dlls, I thought it was appropriate to use them.

I modified my bld.bat to link libpng_static.lib and zlibstatic.lib, and my program ran successfully on a vanilla conda without Library\bin on my PATH. On the anaconda mailing list, I suggested a tweak to the documentation at http://conda.pydata.org/docs/build.html .

I think this issue can be closed.

[ilanschnell]

Here is my email response regarding this issue for reference:

I want to give some background on why LIBRARY_PREFIX exists and why LIBRARY_BIN is not currently added to the PATH. We noticed that there where certain packages on Windows which needed to be created using Unix tools, and followed the include/bin/lib directory structure. Because there are already all sorts of files in the regular prefix, we decided to add \Library for those types of things, and the name 'Library' comes from the fact that the packages installed into this location are usually libraries, which are only used to support other packages. It was decided that this would be a standard location, but only for the purpose of build dependency packages. That means, whenever a (user) package requires a 'Library', it would either statically link or copy files from the "Library" package. If you install Anaconda on Windows, you might have noticed that there isn't even a \Library directory, because its purpose was merely for those build dependencies.

[tadeu]

The binaries from hdf5 package (1.8.15.1 build 2) are installed into LIBRARY_BIN, is the package wrong?

[tadeu]

@ilanschnell The documentation seems to be confusing, could you please clarify it?

It says

When building “Unix-style” packages on Windows, which are then usually statically linked to executables, we do this in a special Library directory under the build prefix.

but according to your reply, this is not about unix-style packages, but about static libraries (or even header-only libraries) that are build dependencies only.

[ChrisBarker-NOAA]

This is all well and good -- Library is supposed to be where bulid-time dependencies are put, And a number of libs create both libs and .dlls when built, so dlls end up there, even when not intended.

But I thought the whole point of conda was, to well, manage pacakges -- so it SHOULD be abel to support providing dlls for stuff (like libpng, etc,) that multipel other pacakges might want to use -- why have them all statically lnk?

So where should dlls that are intended to be shared by other conda-managed packages go??

( and #509 seems to indicate that Library/lib (or bin or ???) will be used that way now -- but I lost track of the discussion)

[msarahan]

Currently, here is the scheme (mostly the library folder mimics Unix):

Library/bin: executables and dlls
Library/lib: import libraries and static libs (both are .lib)
Library/include: headers

Note that there is no lib32/lib64 - that is determined by the root installation.

We anticipate conflicts at some point. When that starts to become an issue, we will embed paths in executables, either by patching source code, or by emerging manifests.

[jrovegno]

Only for reference purpose I leave the code of one batch file saved in Scripts/ to add LIBRARY_BIN to PATH. In my case with this I can use some useful tools installed in Library/bin like sqlite3.

@echo off

for %%i in ("%~dp0..") do (
    set ANACONDA=%%~fi
    )

set LIBRARY_BIN=%ANACONDA%\Library\bin
set "PATH=%LIBRARY_BIN%;%PATH%"

echo Added %LIBRARY_BIN% to PATH.