pcre unknown error

[staticfloat]

There seems to be some weirdness with printing arrays of floats:

julia> 1:10
1:10

julia> z = sin(1:10)
10-element Float64 Array:
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef
 #undef

julia> z[1]
0.8414709848078965

julia> z[1:2]
2-element Float64 Array:
 #undef
 #undef

This is on OSX 10.8, although I wonder if that can possibly have anything to do with it. :P

[StefanKarpinski]

That's weird. I wonder if you don't have to do a make cleanall testall. Jeff has done some fairly significant surgery on the internal representations of objects that could lead to strange behavior and crashes if objects are linked together that were built under different assumptions.

[StefanKarpinski]

For the record, I'm on the same setup and see normal behavior:

julia> sin(1:10)
10-element Float64 Array:
  0.841471
  0.909297
  0.14112 
 -0.756802
 -0.958924
 -0.279415
  0.656987
  0.989358
  0.412118
 -0.544021

[staticfloat]

Homebrew starts out with a fresh copy of the git repo every time you
install, so there's no need to worry about old cruft.

The test suite comes up clean, and I get #undefs in the readline, basic and
web REPLs.

[StefanKarpinski]

That is super weird. The strangest part is that you can't even actually have #undefs in arrays of floats since they aren't heap-allocated and therefore every possible value means something (possibly NaN). For performance reasons, uninitialized int, float arrays are just filled with whatever's in memory:

julia> Array(Float64,25)
25-element Float64 Array:
 2.14294e-314
 2.17901e-314
 2.12944e-314
 2.12943e-314
 2.12943e-314
 2.17668e-314
 2.12948e-314
 2.12948e-314
 2.17902e-314
 2.17901e-314
 2.17842e-314
 2.17821e-314
 2.12943e-314
 2.12944e-314
 2.1765e-314 
 2.17833e-314
 2.17842e-314
 2.14376e-314
 2.17904e-314
 2.17644e-314
 2.12943e-314
 2.12944e-314
 2.12952e-314
 2.14309e-314
 2.17821e-314

That's why I suspected recent representation changes as a culprit.

[staticfloat]

Is this printing done in Julia, or in C? If it's in Julia, where does it
happen so I can try and hunt down what's going on?

On Mon, Aug 27, 2012 at 2:18 PM, Stefan Karpinski
notifications@github.comwrote:

That is super weird. The strangest part is that you can't even actually
have #undefs in arrays of floats since they aren't heap-allocated and
therefore every possible value means something (possibly NaN). For
performance reasons, uninitialized int, float arrays are just filled with
whatever's in memory:

julia> Array(Float64,25)25-element Float64 Array:
2.14294e-314
2.17901e-314
2.12944e-314
2.12943e-314
2.12943e-314
2.17668e-314
2.12948e-314
2.12948e-314
2.17902e-314
2.17901e-314
2.17842e-314
2.17821e-314
2.12943e-314
2.12944e-314
2.1765e-314
2.17833e-314
2.17842e-314
2.14376e-314
2.17904e-314
2.17644e-314
2.12943e-314
2.12944e-314
2.12952e-314
2.14309e-314
2.17821e-314

That's why I suspected recent representation changes as a culprit.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8071092.

[StefanKarpinski]

It's in base/show.jl. Search for "#undef" and follow the breadcrumbs.

[staticfloat]

Alright, I've figured out that it has something to do with the
install_name_tool patching that I'm doing to the julia executable to get
it to fit into Homebrew.

Essentially, in your makefile, you have the line:

install_name_tool -rpath $(BUILD)/lib $(PREFIX)/lib
$(PREFIX)/bin/julia-release-readline

I patch that to be:

install_name_tool -rpath $(BUILD)/lib HOMEBREW_PREFIX/lib
$(PREFIX)/bin/julia-release-readline

This allows Julia to be installed into $HOMEBREW_PREFIX/Cellar/julia, and
have all its files tucked away in there in their own little include,
lib, bin, etc.... folders, while everything gets symlinked into
$HOMEBREW_PREFIX/{bin,lib,include}.

To accomodate this, I change the rpath so that Julia can find all of the
other libraries such as fftw which isn't sitting in Julia's
installation directory, but in its own little world in the Homebrew cellar.
Everything is symlinked into the $HOMEBREW_PREFIX directory however, so
I thought this would be enough, but apparently not.

I've confirmed that the install_name_tool step is the one that causes
Julia to not be able to print out floats in arrays, but I have no idea how
to figure out why this is happening. Is there a way to get Julia to barf on
not being able to load a dependency or something? Is there a "verbose"
mode to see what Julia has dynamically linked with, if there's a freak
accident and Julia is linking with the wrong version of some library?

Thanks!

On Mon, Aug 27, 2012 at 2:25 PM, Stefan Karpinski
notifications@github.comwrote:

It's in base/show.jlhttps://github.com/JuliaLang/julia/blob/master/base/show.jl.
Search for "#undef" and follow the breadcrumbs.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8071329.

[JeffBezanson]

The trys used to catch undefs in show.jl should check that the exception is an UndefRefError.

[staticfloat]

Is it normal for an Array of type Float to be filled with #undef's as well?

julia> Array(Float,2,2)
2x2 Float Array:
 #undef  #undef
 #undef  #undef

As opposed to:

julia> Array(Float64,2,2)
2x2 Float64 Array:
 9.88131e-324  6.94485e-310
 9.88131e-324  6.94485e-310

[StefanKarpinski]

Is it normal for an Array of type Float to be filled with #undef's as
well?

E.g.:

julia> Array(Float,2,2)
2x2 Float Array:
#undef #undef
#undef #undef

This is actually normal since Array{Float} is an array of pointers to heap-allocated objects which happen to be of type Float.

[JeffBezanson]

Come to think of it, we should probably rename Float since people probably think it is C's float type (and you can hardly blame them!) when it is actually extremely different. Maybe it should be FloatingPoint?

[StefanKarpinski]

Especially given that the analogy with Int no longer holds. FloatingPoint
is a good name.

On Tue, Aug 28, 2012 at 3:38 PM, Jeff Bezanson notifications@github.comwrote:

Come to think of it, we should probably rename Float since people
probably think it is C's float type (and you can hardly blame them!) when
it is actually extremely different. Maybe it should be FloatingPoint?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8104274.

[staticfloat]

If the big difference between Float and Float64 is that Float is Heap-allocated and Float64 is stack-allocated, I don't think FloatingPoint is such a good idea, because although you're trying to use this name to mean "Pointer to a float" it is easily confused with "Floating-point number". Therefore, to me, FloatingPoint seems exactly the same as a float from C, just slightly more verbose.

Perhaps something like HeapFloat or FloatRef or something would be better understood?

Also, @JeffBezanson; you said that the try statements should check for an UndefRefError; is there a way I can find dynamic libraries that aren't being loaded properly? So far nothing is complaining in my setup, and the test suites pass, but there's obviously a difference between when I muck around with the rpath and when I don't.

[StefanKarpinski]

No, that's not really the difference — any Julia object can be heap or stack allocated. The difference is that Float is an abstract type — there are no Float objects — there are Float32 and Float64 objects which implement the Float abstraction. Therefore, an Array{Float} has to be represented as an array of pointers to heap-allocated objects, because the actual values could be Float32 or Float64 or potentially some other implementation of Float that someone creates, say BigFloat — which can have arbitrary size. An Array{Float64}, on the other hand, has the exact same semantics but because Float64 is a concrete type and immutable, we can just store the values inline in the array like C or Fortran do. (Of course, the array itself will be heap-allocated, so they values are in the heap, but not as individual boxed values.)

So the point of FloatingPoint is that it is the abstraction of any kind of floating-point representation: Float32, Float64, Float128, BigFloat, etc. However, it is entirely possible that we should just get rid of the Float type altogether. We use it in a bunch of places, but we mostly mean Union(Float32,Float64) in all of those places and the code would probably break if BigFloat were introduced as a subtype of Float. Maybe Real should be the immediate supertype of Float32 and Float64. After all, what abstract operations make sense to anything that is a floating-point representation but don't make sense for a different representation of a real number, like a Rational? The only things I can think of are things like nextfloat which doesn't make any sense for a rational number (there is no next rational), or extracting the exponent or mantissa. In fact, nextfloat doesn't even make sense for BigFloat although extracting the exponent and mantissa as BigInt values does (I'm not sure if that's how it's done internally).

[staticfloat]

Ah, I see. That makes sense, and I agree that most people would get
confused by the difference between Float and Real, as it seems like a
very fine line to draw.

On Tue, Aug 28, 2012 at 2:06 PM, Stefan Karpinski
notifications@github.comwrote:

No, that's not really the difference — any Julia object can be heap or
stack allocated. The difference is that Float is an abstract type — there
are no Float objects — there are Float32 and Float64 objects which
implement the Float abstraction. Therefore, an Array{Float} has to be
represented as an array of pointers to heap-allocated objects, because the
actual values could be Float32 or Float64 or potentially some other
implementation of Float that someone creates, say BigFloat — which can
have arbitrary size. An Array{Float64}, on the other hand, has the exact
same semantics but because Float64 is a concrete type and immutable, we
can just store the values inline in the array like C or Fortran do. (Of
course, the array itself will be heap-allocated, so they values are in the
heap, but not as individual boxed values.)

So the point of FloatingPoint is that it is the abstraction of any kind
of floating-point representation: Float32, Float64, Float128, BigFloat,
etc. However, it is entirely possible that we should just get rid of the
Float type altogether. We use it in a bunch of places, but we mostly mean
Union(Float32,Float64) in all of those places and the code would probably
break if BigFloat were introduced as a subtype of Float. Maybe Realshould be the immediate supertype of
Float32 and Float64. After all, what abstract operations make sense to
anything that is a floating-point representation but don't make sense for a
different representation of a real number, like a Rational? The only
things I can think of are things like nextfloat which doesn't make any
sense for a rational number (there is no next rational), or extracting the
exponent or mantissa. In fact, nextfloat doesn't even make sense for
BigFloat although extracting the exponent and mantissa as BigInt values
does (I'm not sure if that's how it's done internally).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8107135.

[JeffBezanson]

True, it would simplify things to have only Real and not Float. Let's go through and replace Float with either Real or a union of known machine types, as appropriate.

[StefanKarpinski]

Makes sense. I think for the few things like exponent or mantissa extraction we can do duck typing. There seems to be a a slippery slope between floating-point and other real abstractions anyway.

[JeffBezanson]

Actually one thing Float is potentially useful for is knowing when something like compensated summation is worthwhile. The interface also includes things like prevfloat and nextfloat that don't make sense for arbitrary precision.

[StefanKarpinski]

Right, but prevfloat and nextfloat don't make sense for BigFloat either. So maybe a different name is advisable — either for the class of things where those concepts make sense, or for BigFloat. I think that BigFloat is correctly named: it is still floating-point even though the precision is no longer fixed. Fixed-precision is really the issue. So maybe that should be the name? Calling it FixedPrecision is kind of awkward, but that's ok since you usually shouldn't be using it. But that is precisely when it makes sense to use compensated summation and when it makes sense to ask for the previous or next possible value.

[JeffBezanson]

Using the word "fixed" could create confusion with fixed point. I looked up a couple definitions of "floating point" and it seems agreed that it refers to a representation with a fixed number of digits and an exponent. So BigFloat is the misnamed thing; if it can really have any number of digits it doesn't need the exponent and isn't floating point.

[staticfloat]

And yet there's a nice analogy of BigFloat to BigInt, and I'm pretty sure
BigInt is a well-established name. If I know there is a BigInt, chances
are I'm going to be able to guess that there's a BigFloat. Having to
remember something like "HighPrecisionFloat" isn't going to be as intuitive
or easy.

On Tue, Aug 28, 2012 at 3:05 PM, Jeff Bezanson notifications@github.comwrote:

Using the word "fixed" could create confusion with fixed point. I looked
up a couple definitions of "floating point" and it seems agreed that it
refers to a representation with a fixed number of digits and an exponent.
So BigFloat is the misnamed thing; if it can really have any number of
digits it doesn't need the exponent and isn't floating point.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1221#issuecomment-8108930.

[johnmyleswhite]

Jeff's point suggests that BigFloat is probably better named BigReal or something of that sort.

[JeffBezanson]

I think BigFloat could refer to a type with a particular number of digits, but as many as you want. Thus each BigFloat number has an associated number of digits, and thus can implement nextfloat etc.

[StefanKarpinski]

Quoting wikipedia:

The term floating point refers to the fact that the radix point (decimal point, or, more commonly in computers, binary point) can "float"; that is, it can be placed anywhere relative to the significant digits of the number. This position is indicated separately in the internal representation, and floating-point representation can thus be thought of as a computer realization of scientific notation.

So you could very well have an arbitrary precision floating-point type. I'm not sure if this is how BigFloat is implemented, but it's a very different thing than, e.g., Rational{BigInt}. The article goes on to say:

Where greater precision is desired, floating-point arithmetic can be implemented (typically in software) with variable-length significands (and sometimes exponents) that are sized depending on actual need and depending on how the calculation proceeds. This is called arbitrary-precision floating point arithmetic.

Obviously, wikipedia is not definitive, but I think it does generally reflect a pretty reasonable consensus. Maybe we should move this discussion over to the issue I created for it: #1231.

[StefanKarpinski]

I think BigFloat could refer to a type with a particular number of digits, but as many as you want. Thus each BigFloat number has an associated number of digits, and thus can implement nextfloat etc.

I don't think this is standard nomenclature at all.

[nolta]

I believe if we switch to MPFR, then BigFloat will behave as Jeff described.

[StefanKarpinski]

Ah, interesting. So there are two possible very distinct behaviors: what MPFR provides, which is variable-precision floating point, which could be written as something like BigFloat{n} where the n parameter is the number of bits of precision. What I thought it was was precise, variable-precision floating-point arithmetic, where both the exponent and the mantissa are effectively BigInts.

[JeffBezanson]

I'm not sure there are reasonable alternatives to what MPFR provides; if you try to keep results exact the number of digits can keep growing forever, giving unreasonable performance. So it may very well be that a number that is Real but not Integer, Rational, etc. is de-facto floating point. But then you need a way to check for that; checking for Real doesn't work since the number could be an exact integer.

[JeffBezanson]

I believe @nolta fixed the masking of the real error; can you get better information about the exception now?

[staticfloat]

Well, hopefully we're moving in the right direction:

julia> Array(Float64,2,2)

2x2 Float64 Array:
Error showing value of type Array{Float64,2}:
info: unknown error

[staticfloat]

Looks like that might be coming out of pcre.jl, line 64?

[staticfloat]

Just wanted to ping people on this and say that I'm still having this issue. I've managed to narrow it down to a difference between my Homebrew-compiled libjulia-release.dylib and my compiled-externally libjulia-release.dylib, and their respective lib/julia/ folders. E.g. if I copy in the compiled-externally libjulia-release.dylib and lib/julia/ folders, I get the proper output again.

I'm having difficulty coming up with ways to compare the two dylibs, (I've even tried stuff like diffing the output of nm, but name mangling makes this pretty much useless). I know that the lib/julia/ directories are identical EXCEPT for the sys.ji files...... but these files are binary, so again, I don't know how to compare them.

[nolta]

Could you pull the latest version, and tell us what the error code is?

[staticfloat]

julia> Array(Float64,2,2)

2x2 Float64 Array:
Error showing value of type Array{Float64,2}:
info: unknown error -28

[staticfloat]

@nolta; I've managed to narrow it down to line 574 in show.jl. I've also managed to figure out that it seems to be a scoping/exporting/loading problem of some kind:

julia> Array(Float64,2,2)
2x2 Float64 Array:
Error showing value of type Array{Float64,2}:
info: unknown error -28

julia> load("show.jl")

julia> Array(Float64,2,2)
2x2 Float64 Array:
 0.0  0.0
 0.0  0.0

I figured out it was that call to alignment by putting print( Array(Float64,2,2) ) into a file and running it on the command-line:

$ julia test.jl
2x2 Float64 Array:
info: unknown error -28
 in alignment at show.jl:574
 in print_matrix at show.jl:644
 in print_matrix at show.jl:706
 in show at show.jl:783
 in print at string.jl:7
 in load_now at util.jl:231
 in load_now at util.jl:245
 in require at util.jl:174
 in process_options at client.jl:178
 in _start at client.jl:232
at /Users/sabae/Desktop/test.jl:1
 in load_now at util.jl:231
 in load_now at util.jl:245
 in require at util.jl:174
 in process_options at client.jl:178
 in _start at client.jl:232
 in load_now at util.jl:256
 in require at util.jl:174
 in process_options at client.jl:178
 in _start at client.jl:232

[nolta]

Hmm. Error -28 means "a pattern that was compiled by the 8-bit library is passed to a 16-bit library function, or vice versa." Can you post base/pcre_h.jl to gist?

[staticfloat]

I'm actually not certain that this is a pcre error anymore, but here you go.

[nolta]

I tried installing julia w/ homebrew, but i got the following error:

$ brew install gfortran
$ brew install --HEAD julia
...
==> Installing julia dependency: openblas
==> Downloading http://github.com/xianyi/OpenBLAS/zipball/v0.2.3
Already downloaded: /Library/Caches/Homebrew/openblas-0.2.3.zip
==> Using Homebrew-provided fortran compiler.
This may be changed by setting the FC environment variable.
==> make CC=cc  FC=/usr/local/bin/gfortran
      __gfortrani_gfc_itoa in libgfortran.a(error.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_nehalemp-r0.2.3.dylib] Error 1
make: *** [shared] Error 2

which was preceding by this unrelated warning:

$ brew tap homebrew/dupes
$ brew tap staticfloat/julia
...
Warning: Could not tap staticfloat/julia/suite-sparse over mxcl/master/suite-sparse

[staticfloat]

The tap error is not an issue, it's just because I have a custom version of suite-sparse that uses OpenBLAS as opposed to Accelerate as the backing BLAS library. The julia formula ignores mxcl's suite-sparse and uses ours instead.

Can you post the output of the following commands for me? I have the feeling that you have conflicting fortran compilers:

• env to take a look at your PATH, etc....
• which gfortran
• gfortran --print-file-name libgfortran.a
• nmgfortran --print-file-name libgfortran.a| grep __gfortrani_gfc_itoa (You can cut out the nm: no name list entries if you wish)

Thanks!

[nolta]

$ env | egrep 'PATH|LD'
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/X11/bin:/usr/texbin
$ which gfortran
/usr/local/bin/gfortran
$ gfortran --print-file-name libgfortran.a
/usr/local/Cellar/gfortran/4.2.4-5666.3/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64/libgfortran.a
$ nm `gfortran --print-file-name libgfortran.a` 2>/dev/null | grep __gfortrani_gfc_itoa 
0000000000000240 T __gfortrani_gfc_itoa
                 U __gfortrani_gfc_itoa

[staticfloat]

EDIT: I don't get why markdown doesn't get applied to replies from emails sometimes.

Can you post the full output of brew install -v staticfloat/julia/openblas, along with brew --config and brew doctor?

[nolta]

$ brew doctor
Your system is raring to brew.
$ brew --config
HOMEBREW_VERSION: 0.9.3
HEAD: f899878220668c7c7f0fcf43c6d294a52b7e79ed
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit arrandale
OS X: 10.8.2-x86_64
Xcode: 4.5.1
CLT: 4.5.0.0.1.1249367152
LLVM-GCC: build 2336
Clang: 4.1 build 421
X11: 2.7.3 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

I can post the entire 16,898 line output of brew install -v staticfloat/julia/openblas if you'd like, but here's what i suspect is the relevant bit:

/usr/bin/make -j 4 -C exports dyn
make[1]: warning: -jN forced in submake: disabling jobserver mode.
perl ./gensymbol osx x86_64 _ 1 0  0 0 > osx.def
cc  -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC  -DSMP_SERVER -DMAX_CPU_NUMBER=4 -DASMNAME=_ -DASMFNAME=__ -DNAME=_ -DCNAME= -DCHAR_NAME=\"_\" -DCHAR_CNAME=\"\" -DNO_AFFINITY -I.. -all_load -headerpad_max_install_names -install_name /private/tmp/openblas-9ZG1/xianyi-OpenBLAS-e552452/exports/../libopenblas_nehalemp-r0.2.3.dylib -dynamiclib -o ../libopenblas_nehalemp-r0.2.3.dylib ../libopenblas_nehalemp-r0.2.3.a -Wl,-exported_symbols_list,osx.def  -L/usr/local/Cellar/gfortran/4.2.4-5666.3/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/local/Cellar/gfortran/4.2.4-5666.3/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/local/Cellar/gfortran/4.2.4-5666.3/bin/../lib/gcc -L/usr/local/Cellar/gfortran/4.2.4-5666.3/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../..  -lgfortran -lgfortran -lSystem -lSystem  
brew: superenv removed: -O2 -Wall -m64
Undefined symbols for architecture x86_64:
  "___divti3", referenced from:
      __gfortran_pow_i16_i4 in libgfortran.a(pow_i16_i4.o)
      __gfortran_pow_i16_i8 in libgfortran.a(pow_i16_i8.o)
      __gfortran_pow_i16_i16 in libgfortran.a(pow_i16_i16.o)
      _convert_integer in libgfortran.a(list_read.o)
  "___modti3", referenced from:
      _specific__mod_i16 in libgfortran.a(_mod_i16.o)
  "___udivti3", referenced from:
      __gfortrani_gfc_itoa in libgfortran.a(error.o)
      __gfortrani_read_radix in libgfortran.a(read.o)
      __gfortrani_read_decimal in libgfortran.a(read.o)
  "___umodti3", referenced from:
      __gfortrani_gfc_itoa in libgfortran.a(error.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [libopenblas_nehalemp-r0.2.3.dylib] Error 1
make: *** [shared] Error 2
Error: Failure while executing: make CC=cc\  FC=/usr/local/bin/gfortran

[staticfloat]

Excellent, this is actually the same error as reported here, by samueljohn. I should have fixed it up, just brew update and try again.

[nolta]

Ok, thanks. I've successfully installed julia w/ homebrew, and all the tests pass.

However, i cannot reproduce your problem:

julia> Array(Float64,2,2)
2x2 Float64 Array:
 NaN             NaN           
   4.82208e-321    8.00386e-322

[staticfloat]

Faaaaantastic. My next question would be if the homebrew Julia executable is linking against the libraries compiled by Homebrew, or other libraries. You can check via lsof (Where 14446 is the PID of julia-release-readline):

$ lsof -p 14446 | grep REG
julia-rel 14446 sabae  txt      REG                1,2     30740 3879959 /Users/sabae/.homebrew/Cellar/julia/HEAD/bin/julia-release-readline
julia-rel 14446 sabae  txt      REG                1,2    421260  539491 /Users/sabae/.homebrew/Cellar/readline/6.2.4/lib/libreadline.6.2.dylib
julia-rel 14446 sabae  txt      REG                1,2  14269984 3880281 /Users/sabae/.homebrew/Cellar/julia/HEAD/lib/libjulia-release.dylib
julia-rel 14446 sabae  txt      REG                1,2    235016  849602 /Users/sabae/.homebrew/Cellar/pcre/8.31/lib/libpcre.1.dylib
julia-rel 14446 sabae  txt      REG                1,2     31416 3880280 /Users/sabae/.homebrew/Cellar/julia/HEAD/lib/libgrisu.dylib
julia-rel 14446 sabae  txt      REG                1,2    103240 3880277 /Users/sabae/.homebrew/Cellar/julia/HEAD/lib/libfdm.dylib
julia-rel 14446 sabae  txt      REG                1,2     27296 3880282 /Users/sabae/.homebrew/Cellar/julia/HEAD/lib/librandom.dylib
julia-rel 14446 sabae  txt      REG                1,2  12293972  836088 /Users/sabae/.homebrew/Cellar/openblas/0.2.3/lib/libopenblas_penrynp-r0.2.3.dylib
julia-rel 14446 sabae  txt      REG                1,2     26900  888204 /Users/sabae/.homebrew/Cellar/fftw/3.3.2/lib/libfftw3_threads.3.dylib
julia-rel 14446 sabae  txt      REG                1,2   1967180  888149 /Users/sabae/.homebrew/Cellar/fftw/3.3.2/lib/libfftw3.3.dylib
julia-rel 14446 sabae  txt      REG                1,2     26996  882771 /Users/sabae/.homebrew/Cellar/fftw/3.3.2/lib/libfftw3f_threads.3.dylib
julia-rel 14446 sabae  txt      REG                1,2   1877868  882718 /Users/sabae/.homebrew/Cellar/fftw/3.3.2/lib/libfftw3f.3.dylib
julia-rel 14446 sabae  txt      REG                1,2    600576   10189 /usr/lib/dyld
julia-rel 14446 sabae  txt      REG                1,2 303271936  327643 /private/var/db/dyld/dyld_shared_cache_x86_64

[nolta]

julia-rel 71076 nolta  txt      REG                1,3     30740 20237475 /usr/local/Cellar/julia/HEAD/bin/julia-release-readline
julia-rel 71076 nolta  txt      REG                1,3    417164 20082929 /usr/local/Cellar/readline/6.2.4/lib/libreadline.6.2.dylib
julia-rel 71076 nolta  txt      REG                1,3  14270008 20237707 /usr/local/Cellar/julia/HEAD/lib/libjulia-release.dylib
julia-rel 71076 nolta  txt      REG                1,3    235016 20083991 /usr/local/Cellar/pcre/8.31/lib/libpcre.1.dylib
julia-rel 71076 nolta  txt      REG                1,3     31416 20237706 /usr/local/Cellar/julia/HEAD/lib/libgrisu.dylib
julia-rel 71076 nolta  txt      REG                1,3    103240 20237703 /usr/local/Cellar/julia/HEAD/lib/libfdm.dylib
julia-rel 71076 nolta  txt      REG                1,3     27296 20237708 /usr/local/Cellar/julia/HEAD/lib/librandom.dylib
julia-rel 71076 nolta  txt      REG                1,3  12322492 20230246 /usr/local/Cellar/openblas/0.2.3/lib/libopenblas_nehalemp-r0.2.3.dylib
julia-rel 71076 nolta  txt      REG                1,3     26900 20103586 /usr/local/Cellar/fftw/3.3.2/lib/libfftw3_threads.3.dylib
julia-rel 71076 nolta  txt      REG                1,3   1963060 20103532 /usr/local/Cellar/fftw/3.3.2/lib/libfftw3.3.dylib
julia-rel 71076 nolta  txt      REG                1,3     26996 20099197 /usr/local/Cellar/fftw/3.3.2/lib/libfftw3f_threads.3.dylib
julia-rel 71076 nolta  txt      REG                1,3   1877868 20099146 /usr/local/Cellar/fftw/3.3.2/lib/libfftw3f.3.dylib
julia-rel 71076 nolta  txt      REG                1,3    600576 16315704 /usr/lib/dyld
julia-rel 71076 nolta  txt      REG                1,3 303185920 18390675 /private/var/db/dyld/dyld_shared_cache_x86_64

[staticfloat]

Well, I am officially out of ideas. Next free moment I have, I'll try to do some more digging; last time I tried this, I was able to narrow it down to some operation that was happening in the "install" step where the julia executable is no longer linking to things within its BUILD directory but is instead linking to things in its PREFIX directory. I'll see if I can narrow down which library is causing the trouble.

[staticfloat]

I think I've finally fixed this particular issue, it just so happens that it was due to the fact that I have a libpcre.0.dylib in my /usr/lib directory, and since my HOMEBREW_PREFIX is not in /usr/local, Julia doesn't automatically link with my Homebrew dependencies, so at compile-time it goes for the OSX-native pcre.

This error would only manifest itself with someone compiling from Homebrew, with a non-standard Homebrew installation directory. Should be fixed for all cases now, so I'm closing it. Good to finally figure this out!

[StefanKarpinski]

Nice sleuthing. That's a nasty situation to figure out.