Recipe for homebrew

[hugovincent]

It'd be nice if there was a recipe for Homebrew (http://mxcl.github.com/homebrew/).

[ViralBShah]

I believe Joshua Griffith is working on it. Is there a way to add email addresses to github Issues?

[StefanKarpinski]

Don't think there is. It's also rather hard to find people on GitHub knowing just their name.

[whoisjake]

+1

I saw rumors of strict version requirements for external dependencies which will make homebrew formula tough. They don't provide versioning other than the most current that someone puts in the formula.

More things like what's suggested in #369 (ie USE_SYSTEM_LLVM=1) would be awesome.

[JeffBezanson]

LLVM 3.0 is a hard requirement (they generally have API changes in each version). We port to new versions of LLVM as soon as they are stable.
All other versions are flexible, but may cause more subtle problems, though this is unlikely.

[raggi]

https://gist.github.com/eaddd8790b6295a076b4 works. I was awaiting my Make.inc correction before pushing it anywhere. I'm out at a café right now so can't run a final test against master. I'm thinking about pointing at a stable sha, and adding home-brews HEAD support.

I also haven't put any effort into making it use system versions, at the moment this is still a big fat build that takes a long time.

I'm thinking I want to send some patches to alter install to install ./julia to $PREFIX/bin/julia instead of $PREFIX/share/julia/julia. Presumably this is desired?

[raggi]

I see, we need to fix the way that sys.ji is loaded to move the bin files.

[staticfloat]

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should search the default system directories for SuiteSparse? Or is there a more specific meaning to USE_SYSTEM_SUITESPARSE?

[ViralBShah]

For now, we have moved all the suitesparse support to extras, and I am hoping that we can make the build system flexible enough to not build some troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should search the default system directories for SuiteSparse? Or is there a more specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

[staticfloat]

So does this mean there is a way to compile without SuiteSparse at all, or
that building with system libraries is not supported?
-E

On Sun, Apr 8, 2012 at 8:59 PM, Viral B. Shah <
reply@reply.github.com

wrote:

For now, we have moved all the suitesparse support to extras, and I am
hoping that we can make the build system flexible enough to not build some
troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering
how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with
USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find
SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should
search the default system directories for SuiteSparse? Or is there a more
specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

---

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

[ViralBShah]

Can you post the error log when you set USE_SYSTEM_SUITESPARSE=1?

The way it is supposed to work is that it bypasses suitesparse in the julia build, and if you try to load("extras/linalg_suitesparse.jl"), it will try to look for libsuitesparse.dylib.

-viral

On 09-Apr-2012, at 9:40 AM, Elliot Saba wrote:

So does this mean there is a way to compile without SuiteSparse at all, or
that building with system libraries is not supported?
-E

On Sun, Apr 8, 2012 at 8:59 PM, Viral B. Shah <
reply@reply.github.com

wrote:

For now, we have moved all the suitesparse support to extras, and I am
hoping that we can make the build system flexible enough to not build some
troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering
how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with
USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find
SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should
search the default system directories for SuiteSparse? Or is there a more
specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

---

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

---

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

[ViralBShah]

I see the problem - the Makefile was modified, which is causing the issue.

-viral

On 09-Apr-2012, at 9:40 AM, Elliot Saba wrote:

So does this mean there is a way to compile without SuiteSparse at all, or
that building with system libraries is not supported?
-E

On Sun, Apr 8, 2012 at 8:59 PM, Viral B. Shah <
reply@reply.github.com

wrote:

For now, we have moved all the suitesparse support to extras, and I am
hoping that we can make the build system flexible enough to not build some
troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering
how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with
USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find
SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should
search the default system directories for SuiteSparse? Or is there a more
specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

---

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

---

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

[staticfloat]

Can you give me a commit to roll back to to test? Also, which makefile? Because as far as I can tell, the Makefile in external/ is generated at compile-time

[ViralBShah]

Can you comment out lines 67-69 in external/Makefile? I wonder if that will disable the building of libsuitesparse altogether.

The problem with libsuitesparse is as follows:

1. The default build process of libsuitesparse builds only .a files
2. Currently, julia builds a shared library out of all the .a files
3. Some linux distributions (Debian) create shared libraries corresponding to every .a file, rather than one shared library like we do
4. Due to this non-standard behaviour, detecting and installing suitesparse is a nightmare
5. Most USE_SYSTEM_XYZ ignore the build process in julia
6. The exception is libsuitesparse, where USE_SYSTEM_SUITESPARSE triggers the build to look for various suitesparse .a files so that it can create a libsuitesparse shared library that julia expects

Immediately, we can disable suitesparse completely from the build, as I have suggested above. I can do that if it works for you - since I won't be able to test it for the next couple of days.

The plan for the long run is to change julia's suitesparse build process so that USE_SYSTEM_SUITESPARSE doesn't have to look around and do stuff, and setting it to 1 will result in the whole thing being ignored.

-viral

On 09-Apr-2012, at 9:40 AM, Elliot Saba wrote:

So does this mean there is a way to compile without SuiteSparse at all, or
that building with system libraries is not supported?
-E

On Sun, Apr 8, 2012 at 8:59 PM, Viral B. Shah <
reply@reply.github.com

wrote:

For now, we have moved all the suitesparse support to extras, and I am
hoping that we can make the build system flexible enough to not build some
troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering
how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with
USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find
SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should
search the default system directories for SuiteSparse? Or is there a more
specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

---

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

---

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

[ViralBShah]

Can brew create standalone dmg files for OS X as well?

-viral

On 09-Apr-2012, at 9:59 AM, Viral Shah wrote:

Can you comment out lines 67-69 in external/Makefile? I wonder if that will disable the building of libsuitesparse altogether.

The problem with libsuitesparse is as follows:

1. The default build process of libsuitesparse builds only .a files
2. Currently, julia builds a shared library out of all the .a files
3. Some linux distributions (Debian) create shared libraries corresponding to every .a file, rather than one shared library like we do
4. Due to this non-standard behaviour, detecting and installing suitesparse is a nightmare
5. Most USE_SYSTEM_XYZ ignore the build process in julia
6. The exception is libsuitesparse, where USE_SYSTEM_SUITESPARSE triggers the build to look for various suitesparse .a files so that it can create a libsuitesparse shared library that julia expects

Immediately, we can disable suitesparse completely from the build, as I have suggested above. I can do that if it works for you - since I won't be able to test it for the next couple of days.

The plan for the long run is to change julia's suitesparse build process so that USE_SYSTEM_SUITESPARSE doesn't have to look around and do stuff, and setting it to 1 will result in the whole thing being ignored.

-viral

On 09-Apr-2012, at 9:40 AM, Elliot Saba wrote:

So does this mean there is a way to compile without SuiteSparse at all, or
that building with system libraries is not supported?
-E

On Sun, Apr 8, 2012 at 8:59 PM, Viral B. Shah <
reply@reply.github.com

wrote:

For now, we have moved all the suitesparse support to extras, and I am
hoping that we can make the build system flexible enough to not build some
troublesome dependencies at all.

-viral

On 08-Apr-2012, at 10:53 PM, Elliot Saba wrote:

I'm taking a poke at making a Julia homebrew recipe, and I'm wondering
how exactly the USE_SYSTEM_XYZ defines work, as when I try compiling with
USE_SYSTEM_SUITESPARSE=1, I get errors about not being able to find
SuiteSparse-SYSTEM/lib/libsuitesparse.dylib

Am I mis-interpreting USE_SYSTEM_SUITESPARSE when I think it should
search the default system directories for SuiteSparse? Or is there a more
specific meaning to USE_SYSTEM_SUITESPARSE?

---

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

---

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

---

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

[ViralBShah]

external/Makefile is handwritten. Just those 3 lines in external/Makefile to be commented out to see if they will disable building suitesparse altogether. I don't think the USE_SYSTEM_SUITESPARSE ever worked reliably before.

-viral

On 09-Apr-2012, at 9:53 AM, Elliot Saba wrote:

Can you give me a commit to roll back to to test? Also, which makefile? Because as far as I can tell, the Makefile in external/ is generated at compile-time

---

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

[ViralBShah]

Two things are to be done in external/Makefile to disable suitesparse

1. Remove suitesparse-wrapper from LIBS
2. Comment out lines 67-69 that check USE_SYSTEM_SUITESPARSE

-viral

On 09-Apr-2012, at 9:53 AM, Elliot Saba wrote:

Can you give me a commit to roll back to to test? Also, which makefile? Because as far as I can tell, the Makefile in external/ is generated at compile-time

---

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

[staticfloat]

brew isn't really meant for creating packaged software, it installs software it to a unique prefix (so each package has its own /bin, /etc, /lib, /include etc....), and then symlinks the results into a global /bin, /include, /lib etc.... thus allowing programs to find eachother, yet maintaining an easy way to uninstall programs. So the installation process doesn't really have anything to do with standalone dmgs at all.

My build process is making it past the SuiteSparse steps now, but there are a few other smaller kinks I need to eradicate. I'll report back in the morning for a tad bit more help with integrating with as many homebrew-available libraries as possible, as I think it would be nice to take advantage of the package manager as much as we can.

[StefanKarpinski]

I didn't know this about homebrew — no wonder it's popular. That's such a
nice model for Installing programs. I don't understand why more packaging
systems don't do it this way. It also makes switching between multiple
versions of the same software dirt simple and transparent — just change a
symlink.

On Monday, April 9, 2012, Elliot Saba wrote:

brew isn't really meant for creating packaged software, it installs
software it to a unique prefix (so each package has its own /bin, /etc,
/lib, /include etc....), and then symlinks the results into a global /bin,
/include, /lib etc.... thus allowing programs to find eachother, yet
maintaining an easy way to uninstall programs. So the installation process
doesn't really have anything to do with standalone dmgs at all.

My build process is making it past the SuiteSparse steps now, but there
are a few other smaller kinks I need to eradicate. I'll report back in the
morning for a tad bit more help with integrating with as many
homebrew-available libraries as possible, as I think it would be nice to
take advantage of the package manager as much as we can.

---

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

[staticfloat]

Alright, I have a brew that actually compiles, which is a good first start. :)

I've managed to use homebrew-supplied readline, glpk, llvm, pcre, lapack and blas, (a few of which I've had to create, so it's not all in homebrew main yet) but I have an error when I try and use brew's fftw; toward the end of the build process, when julia is doing it's "sys0.ji" thing: https://gist.github.com/2347454

I'm not sure why it's looking for libfftw3.bundle, but that file doesn't seem to be installed anywhere on my machine (although I have a libfftw3.dylib, so maybe this is a cross-platform extension problem). My julia-fu is still very weak, so I'm not sure how to edit whatever's going on inside of sys0.ji (I'm not even sure what source compiles down into sys0.ji)

Additionally, I looked at the Makefile in external/ to try and figure out how you're compiling arpack-ng, and it seems you're completely bypassing the configure script and Makefile?

[staticfloat]

Also, I should note that if fixing this fftw issue is something that is within the reach of a julia beginner, giving me a tip on where to start looking for fixing this kind of thing is totally acceptable, I like getting my feet wet. :)

[Keno]

On mac julia looks for the file with three different extensions (.dylib, .bundle and no extension at all) .bundle is just the last one to be checked, so that's what the error message is about. I would assume that fftw3 is not within Julia's runtime library search path. (BTW, the dll loading logic is in dlload.c if you want to have a look).

[ViralBShah]

Julia looks for filenames with extensions .dylib and .bundle on OS X. If it can't find it, since it tries .bundle last, that is the error you see. If you have fftw installed in a standard path, then julia ought to be able to find it. Can you verify it is built correctly and all? I don't see why it should behave any differently than any of the other libraries.

sys0.ji is an intermediate step to building sys.ji. Once we have sys.ji, sys0.ji is not used at all.

Yes, I may be bypassing the build in arpack-ng. This is because I could not get the arpack-ng build process to find openblas and load it, and I simply just link it in manually. I only figured out a couple of days back that I have to use install_name_tool to add @rpath to library paths to make this work. With that knowledge, I think we could now clean up the arpack-ng build process.

If we can get all the dependencies working in brew, I would personally prefer to use brew myself.

-viral

On 10-Apr-2012, at 5:25 AM, Elliot Saba wrote:

Alright, I have a brew that actually compiles, which is a good first start. :)

I've managed to use homebrew-supplied readline, glpk, llvm, pcre, lapack and blas, (a few of which I've had to create, so it's not all in homebrew main yet) but I have an error when I try and use brew's fftw; toward the end of the build process, when julia is doing it's "sys0.ji" thing: https://gist.github.com/2347454

I'm not sure why it's looking for libfftw3.bundle, but that file doesn't seem to be installed anywhere on my machine (although I have a libfftw3.dylib, so maybe this is a cross-platform extension problem). My julia-fu is still very weak, so I'm not sure how to edit whatever's going on inside of sys0.ji (I'm not even sure what source compiles down into sys0.ji)

Additionally, I looked at the Makefile in external/ to try and figure out how you're compiling arpack-ng, and it seems you're completely bypassing the configure script and Makefile?

---

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

[staticfloat]

Thanks loladiro! That helped a lot. I've updated the commit, and am now able to build julia with a homebrew-provided fftw. The problem was that the $HOMEBREW_PREFIX/lib folder is not in my $PATH, which I think it needs to be for julia to find it (Because julia loads it as a runtime library, as opposed to the other libraries, which are compile-time). I ended up just symlinking the fftw libraries into julia's /lib folder.

With all homebrew dependencies installed, the julia install itself (including arpack-ng, and doubleprecision and such) takes less than 2 minutes, an order of magnitude faster than it took previously, when compiling all dependencies every time.

New formula is here; I'll see about getting this pulled into homebrew-alt soon. (This won't be accepted in homebrew proper, as julia does not yet have a stable release, but tapping the alt repo is simple for people that wish to install julia)

[staticfloat]

I'm going through the brew right now with the homebrew people, and we've come across some strange things in the Julia build process, that I'm hoping you all can shed some light upon:

• The compiler does not respect CPPFLAGS at all, and I had to shoe-horn the include directories and such of the system into CFLAGS as a work-around.
• The Fortran compiler does not use FCFLAGS, instead it uses FFLAGS.... is this a competing standard, or something that is Julia-specific?
• When trying to compile with clang, I get an error in fdlibm:

Undefined symbols for architecture x86_64:
  "_isnanf", referenced from:
      _scalbf in e_scalbf.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any light you can shed on these problems?

[ViralBShah]

Yes, we do not have CPPFLAGS, since the issue has never come up. What do you use it for?

Is FCFLAGS the standard thing? That is easy to change.

The fdlibm stuff is bizarre. I have never seen an fdlibm error before. Perhaps s_isnan.c is not getting linked somehow?

-viral

On 13-Apr-2012, at 10:45 PM, Elliot Saba wrote:

I'm going through the brew right now with the homebrew people, and we've come across some strange things in the Julia build process, that I'm hoping you all can shed some light upon:

• The compiler does not respect CPPFLAGS at all, and I had to shoe-horn the include directories and such of the system into CFLAGS as a work-around.
• The Fortran compiler does not use FCFLAGS, instead it uses FFLAGS.... is this a competing standard, or something that is Julia-specific?
• When trying to compile with clang, I get an error in fdlibm:

Undefined symbols for architecture x86_64:
 "_isnanf", referenced from:
     _scalbf in e_scalbf.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Any light you can shed on these problems?

---

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

[StefanKarpinski]

isnan and isinf are annoying because they're often macros and weird shenanigans go into defining them.

[ViralBShah]

They are not macros in fdlibm.

-viral

On 14-Apr-2012, at 7:22 AM, Stefan Karpinski wrote:

isnan and isinf are annoying because they're often macros and weird shenanigans go into defining them.

---

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

[staticfloat]

Quoting this: http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.68/html_node/Preset-Output-Variables.html

CPPFLAGS is described:

This variable's contents should contain options like -I, -D, and -U that affect only the behavior of the preprocessor.

As opposed to the description of CFLAGS:

If a compiler option affects only the behavior of the preprocessor (e.g., -Dname), it should be put into CPPFLAGS instead. If it affects only the linker (e.g., -Ldirectory), it should be put into LDFLAGS instead. If it affects only the compiler proper, CFLAGS is the natural home for it.

[staticfloat]

That's fine, suite-sparse is eventually going to be migrated from homebrew
main into homebrew-science. Until then, I'll remove suite-sparse from my
tap, to avoid the warning.
-E

On Tue, May 22, 2012 at 11:26 AM, Mike Nolta <
reply@reply.github.com

wrote:

When i run $ ./bin/brew tap staticfloat/julia i get the following warning

Warning: Could not tap staticfloat/julia/suite-sparse over
mxcl/master/suite-sparse

---

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

[nolta]

Ok, i've successfully built julia using homebrew. Thanks @staticfloat, this is really neat!

So neat, in fact, that now i'm wondering if we could use homebrew on all platforms. How hard could it be to port to linux?

[StefanKarpinski]

Wow! Congrats and thanks, @staticfloat. Epic win, after a huge amount of effort. Not so sure about using homebrew everywhere...

[staticfloat]

The Linux port idea is ongoing, but very slow progress, as nobody is really
spearheading it. There's also a lot of effort that's gone into Homebrew
that is in reaction to mac-specific problems.

In short, the amount of work to port it to linux is non-trivial.

[nolta]

$ ./bin/brew test julia
Testing julia
==> julia runtests.jl all

Error: julia: failed

But this works

$ cd Cellar/julia/HEAD/share/julia/test/
$ ~/homebrew/bin/julia runtests.jl all

[staticfloat]

Did you add your homebrew bin/ to your path?
-E

On Tue, May 22, 2012 at 12:26 PM, Mike Nolta <
reply@reply.github.com

wrote:

$ ./bin/brew test julia
Testing julia
==> julia runtests.jl all

Error: julia: failed

But this works

$ cd Cellar/julia/HEAD/share/julia/test/
$ ~/homebrew/bin/julia runtests.jl all

---

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

[vqv]

@staticfloat I've successfully built julia on two different systems using your formula. Thanks! However, I ran into one hiccup on my second machine. I have a fresh install of homebrew there. The julia formula brings in all of the dependencies, but it did not warn me that I did not have gfortran installed. So openmpi was built without fortran support. I only realized I forgot to install gfortran after the build process for arpack-ng complained. The solution was to uninstall openmpi, install gfortran, and then rebuild openmpi before continuing with the rest of the dependencies for julia.

[nolta]

No, and the test succeeds after adding it.

However, you're supposed to be able to have multiple homebrew repositories on the same machine, which only seems like it would work if all brew commands are relative to their repo. Otherwise how do i know which julia is being called?

[staticfloat]

@vqv: Awesome, this is exactly the kind of testing needed. I forgot to include gfortran as a requirement..... funny that openmpi can install without it, I've included gfotran before openmpi so everything should be good to go now.

@nolta: Whether or not your shell knows how to find a piece of software is a shell problem, not a homebrew problem. Adding <homebrew prefix>/bin to your PATH is necessary, because otherwise your shell won't know where to look for e.g. the julia executable. If you have multiple homebrew installations, all of which are in your path, then the shell will search each directory in your PATH for a matching executable, and whichever one it finds first, it will run. This isn't a homebrew thing, this is an OS thing, and Linux, Windows, and OSX all do this the same way.

That being said, I don't think having the same executable in multiple homebrew installations is really the proper use case. My guess is this is mostly for separating different classes of software (system-level software like libraries, tools that would normally install into /sbin/, as opposed to user-installed software that would normally install into /usr/local/bin/, for example) in which case you would hope to not have too many duplicates shadowing eachother.

I've never felt the need to have multiple homebrew installations on my laptop, but on, for example, a university system, where you want users to be able to install software into their own home directories, yet still maintain a "base" installation across all computers that the student's can't touch, I can see this being very useful.

[nolta]

Homebrew recommends using wget as the template for new formulae.

Here's wget's test function

  def test
    system "#{bin}/wget", "-O", "-", "www.google.com"
  end

All you have to do is replace "julia" with "#{bin}/julia".

[staticfloat]

That's a good change so that users don't get confused as to what the error actually is, but if system "julia" is failing because of a path issue, you will not be able to run the julia interpreter without specifying the full path. (e.g. opening your terminal and running julia will not work)

[nolta]

homebrew already prints the following warning message:

Warning: /Users/nolta/homebrew/bin is not in your PATH
You can amend this by altering your ~/.bashrc file

[vqv]

@staticfloat I just installed julia on a 3rd machine using your formula. The inclusion of gfortran in the dependencies seems to work, and the installation passes the test:

% brew test julia
Testing julia
==> /usr/local/Cellar/julia/HEAD/bin/julia runtests.jl all

Congratulations!

Now to start playing with julia...

[ViralBShah]

@staticfloat Can you try out the new build and install now. I am sure I have lost some features that you may need. Can you review it and git it a try? It's getting into good shape now.

[staticfloat]

Interestingly enough, I've managed to get it to build again, but I am getting some very strange errors when I try and run Julia:

$ ./julia
symbol could not be found jl_enable_color (-1): dlsym(RTLD_DEFAULT, jl_enable_color): symbol not found
symbol could not be found repl_callback_enable (-1): dlsym(RTLD_DEFAULT, repl_callback_enable): symbol not found
LLVM ERROR: Program used external function 'ccall_307' which could not be resolved!

[nolta]

Yeah, i'm seeing the same problem, and upgrading to llvm 3.1 doesn't fix it.

[staticfloat]

Re-trying today, the build process dies with:

cp -rL /private/tmp/homebrew-julia-HEAD-nr0L/usr/lib/julia/* /Users/<user>/.homebrew/Cellar/julia/HEAD/lib/julia
cp: the -H, -L, and -P options may not be specified with the -r option.

Clearly this is a problem with the OSX cp command differing from the Linux cp command. What does the -L option do?

[Keno]

Fixed: 946ccff

-L makes sure symbolic links are followed.

[staticfloat]

Thanks, but I still get the same error as a few days ago:

$ julia
symbol could not be found jl_enable_color (-1): dlsym(RTLD_DEFAULT, jl_enable_color): symbol not found
symbol could not be found repl_callback_enable (-1): dlsym(RTLD_DEFAULT, repl_callback_enable): symbol not found
LLVM ERROR: Program used external function 'ccall_392' which could not be resolved!

[ViralBShah]

Is this perhaps a DLLEXPORT issue?

On Sun, Jun 3, 2012 at 1:14 PM, Elliot Saba
reply@reply.github.com
wrote:

Thanks, but I still get the same error as a few days ago:

   $ julia
   symbol could not be found jl_enable_color (-1): dlsym(RTLD_DEFAULT, jl_enable_color): symbol not found
   symbol could not be found repl_callback_enable (-1): dlsym(RTLD_DEFAULT, repl_callback_enable): symbol not found
   LLVM ERROR: Program used external function 'ccall_392' which could not be resolved!

---

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

-viral

[Keno]

I will just note that the two missing symbols are the only ones not exported by libjulia, but by the repl application

[ViralBShah]

Are you on OS X 10.6? What is different in your environment from the latest Lion and latest dev tools?

[nolta]

The problem seems to be caused by homebrew calling strip on the binaries. This can be disabled by adding

skip_clean, ['bin']

to the julia formula.

[staticfloat]

@nolta; that's what I was going to check next, and it looks like it works! Nicely found. Formula updated, and confirmed to pass all tests on the latest git.

[msabramo]

I also had the symbol not found errors when running the repl and a slight tweak to #387 (comment) fixed it for me.

skip_clean ['bin']

+1 to that change.

[ViralBShah]

@staticfloat Can we reasonably close this issue - now that brew has a way to build julia, even though issues may exist?

[staticfloat]

Sure thing. Any further discussion regarding Homebrew and Julia can happen at my homebrew-julia tap for homebrew.