Unable to build on OSX

[friggeri]

Hi there, greatly interested in Julia, but unable to compile on OSX 10.7.3. I managed to go past the issue with OpenBLAS, but I now have a problem at a further step :

    CC src/jltypes.o
    CC src/gf.o
    CC src/support/hashing.o
    CC src/support/timefuncs.o
    CC src/support/dblprint.o
    CC src/support/ptrhash.o
    CC src/support/operators.o
    CC src/support/socket.o
    CC src/support/utf8.o
    CC src/support/ios.o
    CC src/support/dirpath.o
    CC src/support/htable.o
    CC src/support/bitvector.o
    CC src/support/int2str.o
    CC src/support/dump.o
    CC src/support/libsupportinit.o
    CC src/support/arraylist.o
    LINK src/support/libsupport.a
    CC src/flisp/flisp.o
    CC src/flisp/builtins.o
    CC src/flisp/string.o
    CC src/flisp/equalhash.o
    CC src/flisp/table.o
    CC src/flisp/iostream.o
    CC src/flisp/julia_extensions.o
    LINK src/flisp/libflisp.a
    CC src/flisp/flmain.o
    CC src/flisp/flisp
eval: variable 2.0 has no value
in file unittest.lsp
#0 (lambda)
make[2]: *** [flisp] Error 1
make[1]: *** [flisp/libflisp.a] Error 2
make: *** [julia-release] Error 2

[sergioramos]

+1

[dronir]

I encountered this same problem.

[StefanKarpinski]

@JeffBezanson: looks like Femtolisp is getting a bit of a workout here too.

[JeffBezanson]

This has been seen on some linuxes too. I strongly suspect it's due to using a different version of GCC. Some GCCs, erm, have a different interpretation of femtolisp's code...

[jckarter]

On OS X GCC is forever stuck at 4.2. You might try Clang, which is the favored compiler as of Xcode 4.

[friggeri]

@JeffBezanson Any suggestions to fix this ?

[StefanKarpinski]

Well, there's two issues: how to work around it, and how to fix it. For the work-around, it seems like using a different version of gcc or maybe clang should do the trick. This does work fine in every version of gcc or clang that I've tried, so it may even be a bug in a particular version of gcc. Can you post full gcc version info? For the fix, that's a little harder because Jeff doesn't have your version of gcc to reproduce with.

[JeffBezanson]

It's a long shot, but the first thing I can think of to try, if you're willing, is to remove -DUSE_COMPUTED_GOTO in src/flisp/Makefile. Another thing to try is disabling compiler optimizations, by setting SHIPFLAGS=$(DEBUGFLAGS) at an appropriate point in the same Makefile. This won't affect performance since the lisp bit is only used for the julia front-end (basically just parsing).

Other than that, this is probably quite subtle and I'd need to be able to reproduce the problem locally to work on it.

[dronir]

For me (using OS X 10.7.2):

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

For what is worth, I got the same error with clang.

@JeffBezanson I tried the first trick you suggested (using gcc), and it did get ahead, but now I get the following:

$ make
    CC src/jltypes.o
    CC src/gf.o
    FLISP src/julia_flisp.boot
    FLISP src/julia_flisp.boot.inc
    CC src/ast.o
    CC src/builtins.o
    CC src/module.o
    CC src/codegen.o
    CC src/interpreter.o
    CC src/alloc.o
    CC src/dlload.o
    CC src/sys.o
    CC src/init.o
    CC src/task.o
    CC src/array.o
    CC src/dump.o
    CC src/gc.o
    LINK src/libjulia-release.a
    LINK libjulia-release.dylib
    CC ui/repl.o
    CC ui/repl-basic.o
    LINK uijulia-release-basic
    CC ui/repl-readline.o
    LINK uijulia-release-readline
    LINK ui/webserverjulia-release-webserver
    PERL j/pcre_h.j
    PERL j/errno_h.j
    JULIA sys0.ji
/bin/sh: line 1: 81620 Segmentation fault: 11  ./julia -b stage0.j
make: *** [sys0.ji] Error 139

[StefanKarpinski]

Maybe try make cleanall testall to start the build from scratch. Having different parts built by different compilers can cause issues.

[friggeri]

$ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)

I still have the same problem when removing -DUSE_COMPUTED_GOTO or disabling optimizations.

[dronir]

Hmm, my mistake above, forgot to make cleanall after the changes. After make cleanall, I get the same original error always again, whatever I try; with both or either of those suggestions of @JeffBezanson, both with gcc and clang.

[friggeri]

@dronir Yep, same thing here.

[eternalmatt]

After doing a git pull and updating my local repo, make cleanall testall fixed the issue for me.

[ViralBShah]

@afriggeri, I am using the same gcc on OS X 10.7.3, and don't see any of these issues. This is really strange. I guess that @JeffBezanson needs to try it out on the machine where this fails.

[haarts]

+1
Julia: 89d5ca9
GCC: 4.2.1
OS X: 10.7.3 (fully updated)
Error:

eval: variable 2.0 has no value
in file unittest.lsp
#0 (lambda)
make[2]: *** [flisp] Error 1
make[1]: *** [flisp/libflisp.a] Error 2
make: *** [julia-release] Error 2

[ViralBShah]

Is this somehow a processor dependent issue? I have not seen this on Core 2 Duo (Macbook) or Core i5 (Macbook Pro), using the exact same environment.

[haarts]

I have an i7 2.2GHz 4GB 1333MHz DDR3. With a matte screen. ;)

[ViralBShah]

I would have suggested make USECLANG=1, but that results in a segfault in building sys.ji for me. Also, try make debug USECLANG=1.

[haarts]

$ make cleanall && make debug USECLANG=1 yields the same error with an additional warning from clang (repeats a couple of times):

clang: warning: argument unused during compilation: '-falign-functions'

[friggeri]

Same error for me when using make USECLANG=1 or make debug USECLANG=1. I've got an i7 2.7 GHz / 8GB 1333MHz DDR3.

[ViralBShah]

@JeffBezanson can you try an Intel core i7 box? I think there was someone on the mailing list also reporting the same error on linux. May be something relating to gcc and core i7 code generation that flisp is triggering.

[dronir]

My Macbook is the late 2008 (first unibody) 2.0GHz Intel Core 2 Duo.

[JeffBezanson]

I don't think I have access to a core i7. Just my core i5 and servers that are Xeon as far as the eye can see.

[StefanKarpinski]

@haarts: must be the matte screen. We don't support those.

[ViralBShah]

This is perplexing. :-(

Can you build with make debug and see if you can get a stacktrace on that flisp test that is crashing?

-viral

On 20-Feb-2012, at 12:35 PM, Olli Wilkman wrote:

My Macbook is the late 2008 (first unibody) 2.0GHz Intel Core 2 Duo.

---

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

[dronir]

make debug doesn't produce any additional output.

[ViralBShah]

May have to create the debug version of flisp, and load it into gdb to figure out what's going on.

-viral

On 20-Feb-2012, at 12:45 PM, Olli Wilkman wrote:

make debug doesn't produce any additional output.

---

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

[ViralBShah]

Another thing to try is using gcc 4.6 from hpc.sf.net, which is non-llvm. It is a clean tarball install so its easy to get rid of it.

-viral

On 20-Feb-2012, at 12:45 PM, Olli [email protected] wrote:

make debug doesn't produce any additional output.

---

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

[JeffBezanson]

I just had a crazy idea: it thinks 2.0 is an identifier, which is exactly what would happen if isdigit or strtod did not work as expected, and those functions are locale-dependent! Try messing with your locale settings.

[StefanKarpinski]

This is why locale-dependent behavior is evil. It will be crazy if this is the reason...

[dronir]

I'm pretty sure this might be the case, my locale has the comma as decimal separator. Now if I could only figure out how to change it; changing the setting for number formats in System preferences/Language & Text did not affect it.

[dronir]

Yep. I put the following in my .profile:

export LC_ALL=en_US.UTF-8
export LANG=en_US.UTF-8

Everything works now, the build finishes without further problems and Julia runs nicely.

[StefanKarpinski]

QED: locale-dependent functions are the work of the devil. Jeff, I'm amazed that you managed to figure this out.

[friggeri]

Good call ! It corrected the problem for me too. Do you think it'll be possible to hardwire the locale into femtolisp ? (I'd like to keep my actual locale to its previous setting). Anyway, as a simple fix it works great.

[sebasmagri]

Setting both LC_ALL and LANG to C fixed the issue for me. This is the workaround you were looking for it seems. Only the fix is missing.

[haarts]

This worked for me as well.

[dronir]

I believe only LC_NUMERIC matters, because it's the one that defines the decimal separator. Setting it to any locale which uses a decimal point instead of a comma should be enough.