installing/building on 0.7-beta2, Win64 user account

[PaulSoderlind]

At build CodecZlib (after doing add CodecZlib#master) , I get the following error message (if I am logged in as a User)

ERROR: Can not create symbolic link : Access is denied. : C:\Users\Me\.julia\packages\CodecZlib\POfe\deps\usr\bin\libz.dll

ERROR: Can not create symbolic link : Access is denied. : C:\Users\Me\.julia\packages\CodecZlib\POfe\deps\usr\bin\libz-1.dll

Instead, when logged in as an Admin, then it works.

[bicycle1885]

I've never seen this error. Is that reproducible even after removing CodecZlib (or all packages) and then installing it again?

[staticfloat]

This is happening because Windows can't deal with symlinks, and so when 7zip tries to extract a tarball that contains them, it freaks out. The solution is to, when building a tarball for windows in your builder repository, copy all files and not preserve symlinks. SundialsBuilder recently added a piece of code to do this, you can do something similar here. Eventually, BinaryBuilder will do this for you automatically.

[PaulSoderlind]

This problem remains also after the update earlier today (4 Aug)

[s-celles]

I confirm I faced same issue.
I had to run Julia 1.0.0 as Administrator with Windows 10 to be able to run Pkg.build("CodecZlib")

(I was simply trying to install DataFrames.jl)

[aalexandersson]

I had the same issue on Julia 1.0.0. under Windows 7. I was simply trying to install LightGraphs v1.0.0.

Like @scls19fr did, my solution was to run Julia 1.0.0 as Administrator.

[bicycle1885]

Could anyone try this release https://github.com/bicycle1885/ZlibBuilder/releases/tag/v1.0.2? I cannot reproduce the problem on my Windows 10. So I have no idea what is happening exactly.

[krcools]

You cannot reproduce it on an up-to-date install of Windows 10 because the admin requirement on using mklink has been removed recently. Users on older Win10s and Win7s will still have issues.

[krcools]

Some diagnostics:

• Even though symlink creation fails because of lack of permissions, two zero size files libz.dll and libz-1.dll are created in the bin subdirectory. The tragedy is that these files are not even referred to by the created deps.jl.
• Because these placeholders are there, build CodecZlib succeeds on the second attempt. Unfortunately when CodeZlib is pulled in as a dependency of other packages, no second attempt is undertaken.

I agree with @staticfloat that avoiding symlinks altogether would solve this issue.

[staticfloat]

The next version of BinaryBuilder (being worked on under the sf/bb8 branch) automatically collapses symlinks on Windows so that you get independent copies of any files that would instead be symlinks.

[bicycle1885]

I thought materializing symlinks would solve the problem because there are no symlinks in the distributed archive. v1.0.2 I posted above does that. Isn't that enough?

~/w/T/tmp (master|✚1…) $ ls
Zlib.v1.2.11.x86_64-w64-mingw32.tar.gz include                                logs
bin                                    lib                                    share
~/w/T/tmp (master|✚1…) $ ls -ila bin/
total 2640
60166774 drwxr-xr-x  5 kenta  staff     170 Aug 13 14:47 .
60166734 drwxr-xr-x  8 kenta  staff     272 Aug 13 19:03 ..
60166777 -rwxr-xr-x  1 kenta  staff  447596 Aug 13 14:47 libz-1.2.11.dll
60166776 -rwxr-xr-x  1 kenta  staff  447596 Aug 13 14:47 libz-1.dll
60166775 -rwxr-xr-x  1 kenta  staff  447596 Aug 13 14:47 libz.dll

I don't know how BinaryBuilder.jl and BinaryProvider.jl use these DLL files. So, I kept three equivalent files in the archive, but it may be redundant (in that case, which one should I retain? libz.dll? libz-1.2.11.dll?, or any one?).

[bicycle1885]

I see. So, I'll wait for the next BB release.

[staticfloat]

Isn't that enough?

Yes, that should be enough. So all I'm saying is that BB will do that for you, so you don't have to worry about it in the future.