Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

binary installers #236

Closed
StefanKarpinski opened this issue Oct 20, 2011 · 13 comments · Fixed by pablosanjose/Quantica.jl#238
Closed

binary installers #236

StefanKarpinski opened this issue Oct 20, 2011 · 13 comments · Fixed by pablosanjose/Quantica.jl#238
Assignees
@ViralBShah

Comments

@StefanKarpinski
Copy link
Member

To release and expect more than a handful of hardcore users to try Julia, we need easy binary installers. Viral said he's done this on OS X before. Not sure what we can do on Linux — RPMs? Debian packages?
@ghost ghost assigned ViralBShah Oct 20, 2011
@ViralBShah
Copy link
Member

Mac turned out to be easy. The package just installs a julia-mac directory in the home directory, which can be uninstalled by simply deleting it.

For linux, I think we should just release a tar.gz that people can install wherever they want. I could have made a debian package, but I no longer a debian maintainer. That will automatically happen.

RPMs are painful, and you have all these dependencies that can only be resolved with yum. We are better off with a self-contained tarball on linux, which is statically linked.

-viral

On Oct 20, 2011, at 11:09 AM, Stefan Karpinski wrote:

To release and expect more than a handful of hardcore users to try Julia, we need easy binary installers. Viral said he's done this on OS X before. Not sure what we can do on Linux — RPMs? Debian packages?

Reply to this email directly or view it on GitHub:
#236

@StefanKarpinski
Copy link
Member Author

You're probably right for Linux. Since we include all our own libraries, it should be easy enough to just download a tarball of a precompiled Julia directory with the .git directory removed. On Linux, can we assume that people are savvy enough to untar the tarball where they want it?

@JeffBezanson
Copy link
Member

We can put quick instructions wherever the download link is.
To me this is such a great way to install stuff. Apple's own usability guidelines say not to use installers or packagers if you can avoid it. You're supposed to ship a disk image with a folder in it, and installing equals dragging that folder somewhere. So much better than updating a package database or running scripts that make various mysterious changes.

@JeffBezanson
Copy link
Member

Need a target that builds a statically-linked julia-release-readline.

@ViralBShah
Copy link
Member

We can build statically since commit 475b8ea. The install directory also creates a self-contained tarball that can work out of any directory.

Eventually, once we get some traction, debian packages, RPMs, Mac dmgs etc. will get done. For now, a tarball is sufficient.

@StefanKarpinski
Copy link
Member Author

When I move my julia directory and untar one of these tarballs, I still get this:

$ ./julia-release-readline 
dlopen(libfdm.dylib, 2): image not found
error during init:
could not load module libfdm sys.ji:12

@StefanKarpinski
Copy link
Member Author

Ok, got it to work by setting LD_LIBRARY_PATH: export LD_LIBRARY_PATH=$(JULIA_HOME)/lib. That needs to go in the install instructions for sure.

@StefanKarpinski
Copy link
Member Author

Is there any way we could statically link in all of the libraries in lib/ since we always load them? Then we could just have a single fat binary, which would be kind of nice and simple.

@JeffBezanson
Copy link
Member

Wait a second, our own dlopen should automatically look in julia_home/lib, determined at run time. Do you have a JULIA_HOME environment variable set? If so, that overrides the automatic path finder.

@ViralBShah
Copy link
Member

Yes, we could do that for default libs. Seems avoidable though.

But, I did not encounter this problem in all my testing. I think the current solution should work just fine. Do you have some environment variables that are interfering, like Jeff suggested?

On 30-Oct-2011, at 10:36 PM, Stefan [email protected] wrote:

Is there any way we could statically link in all of the libraries in lib/ since we always load them? Then we could just have a single fat binary, which would be kind of nice and simple.

Reply to this email directly or view it on GitHub:
#236 (comment)

@ViralBShah
Copy link
Member

I believe that this variable is not recognized by os x, unless it is a recent change in lion. Usually it is DYLD...

On 30-Oct-2011, at 10:31 PM, Stefan [email protected] wrote:

Ok, got it to work by setting LD_LIBRARY_PATH: export LD_LIBRARY_PATH=$(JULIA_HOME)/lib. That needs to go in the install instructions for sure.

Reply to this email directly or view it on GitHub:
#236 (comment)

@StefanKarpinski
Copy link
Member Author

This trouble was all from the fact that I do set JULIA_HOME. I now simply don't do that and everything is fine. Sorry for the ruckus.

@ViralBShah
Copy link
Member

Ok - but this is good to know.

-viral

On Mon, Oct 31, 2011 at 11:17 AM, Stefan Karpinski
[email protected]
wrote:

This trouble was all from the fact that I do set JULIA_HOME. I now simply don't do that and everything is fine. Sorry for the ruckus.

Reply to this email directly or view it on GitHub:
#236 (comment)

StefanKarpinski pushed a commit that referenced this issue Feb 8, 2018
@yuyichao @tkelman
Add unsafe_string(::Cstring) on 0.4 (#236)
7570910
LilithHafner pushed a commit to LilithHafner/julia that referenced this issue Oct 11, 2021
@ararslan @andreasnoack
Introduce dependency on SpecialFunctions for erfcinv (JuliaLang#236)
af8bf9c
Keno pushed a commit that referenced this issue Oct 9, 2023
@KristofferC
also match ccalls against (lib, function) (#236)
c644081
IanButterworth pushed a commit that referenced this issue Aug 28, 2024
@DilumAluthgeBot @DilumAluthge
🤖 [backports-release-1.11] Bump the Downloads stdlib from a9d274f to …
598a4de 
…1061ecc (#55615)

Stdlib: Downloads
URL: https://github.com/JuliaLang/Downloads.jl.git
Stdlib branch: master
Julia branch: backports-release-1.11
Old commit: a9d274f
New commit: 1061ecc
Julia version: 1.11.0-rc2
Downloads version: 1.6.0(It's okay that it doesn't match)
Bump invoked by: @IanButterworth
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaLang/Downloads.jl@a9d274f...1061ecc

```
$ git log --oneline a9d274f..1061ecc
1061ecc Fix setting atexit. Fixes trailing download tasks during precompilation (#257)
b871386 Add debug information to `setopt` commands (#248)
51e5321 fix: use invokelatest for easy_hook, avoid race (#241)
05f9ec2 make precompile workload relocatable (#236)
2dd891a Hardcode doc edit backlink (#232)
```

Co-authored-by: Dilum Aluthge <[email protected]>
@pablosanjose pablosanjose mentioned this issue Jan 27, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ViralBShah ViralBShah

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add 32bit support for GreenFunctions pablosanjose/Quantica.jl
3 participants
@StefanKarpinski @ViralBShah @JeffBezanson