search

JuliaLang / julia

The Julia Programming Language
https://julialang.org/
MIT License
44.95k stars 5.42k forks source link

error during bootstrap on OS X #1089

Closed staticfloat closed 11 years ago

staticfloat commented 11 years ago

Hey there, updated to 10.8 and I'm doublechecking that OSX 10.8 can still handle Julia's awesomeness. Everything looked good up until the JULIA usr/lib/julia/sys.ji buildstep. At that point, stuff just dies with error during bootstrap.

I ran make debug, and got a slightly more informative error message:

    JULIA usr/lib/julia/sys.ji
Stack dump:
0.      Running pass 'X86 Machine Code Emitter' on function '@anonymous'
/bin/sh: line 1: 71674 Segmentation fault: 11  /private/tmp/homebrew-julia-HEAD-wSGe/usr/bin/julia-debug-readline -b sysimg.jl

Next debugging steps?

staticfloat commented 11 years ago

I woke up a bit further, and realized that I know how to type gdb. So here's a bit more text for you to chew on:

$ gdb /private/tmp/homebrew-julia-HEAD-wSGe/usr/bin/julia-debug-readline
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ....... done

(gdb) r -b sysimg.jl
Starting program: /private/tmp/homebrew-julia-HEAD-wSGe/usr/bin/julia-debug-readline -b sysimg.jl
Reading symbols for shared libraries ++++++................................................................................................... done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001000f1d22 in llvm::JITDwarfEmitter::EmitDwarfTable ()
(gdb) bt
#0  0x00000001000f1d22 in llvm::JITDwarfEmitter::EmitDwarfTable ()
#1  0x00000001000f7866 in (anonymous namespace)::JITEmitter::finishFunction ()
#2  0x0000000100127a22 in (anonymous namespace)::Emitter<llvm::JITCodeEmitter>::runOnMachineFunction ()
#3  0x000000010031a4d7 in llvm::MachineFunctionPass::runOnFunction ()
#4  0x00000001005993bb in llvm::FPPassManager::runOnFunction ()
#5  0x0000000100598e8c in llvm::FunctionPassManagerImpl::run ()
#6  0x0000000100598ddd in llvm::FunctionPassManager::run ()
#7  0x00000001000eea38 in llvm::JIT::runJITOnFunctionUnlocked ()
#8  0x00000001000eec2a in llvm::JIT::getPointerToFunction ()
#9  0x0000000100050b9f in jl_generate_fptr (f=0x10201e4c0) at codegen.cpp:194
#10 0x000000010004ec89 in jl_apply [inlined] () at /private/tmp/homebrew-julia-HEAD-wSGe/src/julia.h:672
#11 0x000000010004ec89 in jl_trampoline (F=0x10201e4c0, args=0x7fff5fbfe4f8, nargs=0) at builtins.c:673
#12 0x000000010006ceb0 in do_call (f=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>, nargs=0, locals=<value temporarily unavailable, due to optimizations>, nl=<value temporarily unavailable, due to optimizations>) at interpreter.c:53
#13 0x000000010006beb0 in eval (e=0x10201e300, locals=0x0, nl=0) at interpreter.c:119
#14 0x000000010006cc25 in eval_body (stmts=0x10202d390, locals=0x0, nl=0, start=<value temporarily unavailable, due to optimizations>) at interpreter.c:342
#15 0x000000010006bfe4 in eval (e=<value temporarily unavailable, due to optimizations>, locals=0x0, nl=0) at interpreter.c:146
#16 0x0000000100075ce6 in jl_toplevel_eval_flex (e=<value temporarily unavailable, due to optimizations>, fast=<value temporarily unavailable, due to optimizations>, plineno=<value temporarily unavailable, due to optimizations>) at toplevel.c:261
#17 0x00000001000761c8 in jl_parse_eval_all (fname=<value temporarily unavailable, due to optimizations>) at toplevel.c:308
#18 0x0000000100076408 in jl_load (fname=0x100654871 "boot.jl") at toplevel.c:332
#19 0x000000010006fbc9 in julia_init (imageFile=<value temporarily unavailable, due to optimizations>) at init.c:166
#20 0x0000000100001e4d in main (argc=1, argv=0x7fff5fbfee68) at repl.c:271
Warning: the current language does not match this frame.
JeffBezanson commented 11 years ago

Try again with the latest master. I fixed a small llvm type error that could maybe cause something like this. If that doesn't work, you might have to do a more thorough rebuild due to changed system libraries.

staticfloat commented 11 years ago

No dice. Same error. And I just rebuilt everything on the system because I installed OSX 10.8 on Wednesday. (I do clean installs, not in-place upgrades) -E

On Fri, Jul 27, 2012 at 3:36 PM, Jeff Bezanson < reply@reply.github.com

wrote:

Try again with the latest master. I fixed a small llvm type error that could maybe cause something like this. If that doesn't work, you might have to do a more thorough rebuild due to changed system libraries.

Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/1089#issuecomment-7319023

JeffBezanson commented 11 years ago

Is this using apple's LLVM or the one we download and build?

staticfloat commented 11 years ago

I'm the maintainer of the Homebrew install process, and we download/compile a copy of LLVM (3.0), so it's compiled with USE_SYSTEM_LLVM, but the system LLVM libraries are Homebrew-provided ones.

As far as the C compiler goes, I believe this is using Clang 4.0, provided by Apple, which could be the root of the problem, as Clang 4.0 is new with 10.8.

On Fri, Jul 27, 2012 at 5:19 PM, Jeff Bezanson < reply@reply.github.com

wrote:

Is this using apple's LLVM or the one we download and build?

Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/1089#issuecomment-7328928

JeffBezanson commented 11 years ago

Aha --- we are now primarily targeting LLVM 3.1. We made some effort to continue to support 3.0, but I don't test it regularly so I suspect that could be the problem.

staticfloat commented 11 years ago

It's possible that's the issue...... but this compiled just fine on OSX 10.7 not three days ago, so unless there have been significant changes in the last two days, I'm thinking it's more likely something else is freaking out. I'll try to get LLVM 3.1 installed and see if that fixes it.

UPDATE: I updated to LLVM 3.1, and the error is the same. :(

pao commented 11 years ago

1092 reports the same problem on Ubuntu 12.04.

pao commented 11 years ago

No problem on my Lubuntu 11.10 VM. I've taken a snapshot and will do the upgrade to 12.04.

timema commented 11 years ago

I have the same issue on my mac and I still have OS 10.7 It started on Thursday. After that I updated from xcode 4.1 or 4.2 to 4.4 and it still gave the same "error during bootstrap". I have tried it multiple times with clean installs with the same result.

dmbates commented 11 years ago

I have encountered such a problem on an Ubuntu 12.04 amd_64 system. I compiled Julia with clang 3.1 (installed from an Ubuntu ppa) using the system llvm 3.1 (also from the ppa) and the system libreadline. When I enabled the definitions starting with 

if false
    # simple print definitions for debugging. enable these if something
    # goes wrong during bootstrap before printing code is available.
    length(a::Array) = arraylen(a)

in base/sysimg.jl the compilation ended with

    JULIA usr/lib/julia/sys.ji
Warning: New definition writeSegmentation fault (core dumped)
make[1]: *** [/home/bates/build/julia/usr/lib/julia/sys.ji] Error 139
pao commented 11 years ago

And reproduced after upgrading the VM to Lubuntu 12.04. Maybe gcc or glibc?

11Kilobytes commented 11 years ago

Can't be a problem with gcc, it still exists if you build with clang.

pao commented 11 years ago

Yep, right, good point. I'll be taking a shot at bisecting this. Wish me luck.

UPDATE: Infuriatingly, now I cannot reproduce. I was doing builds with make clean && make; perhaps this is some problem with a dependency?

timema commented 11 years ago

make clean && make did not work for me, same error on a mac with os 10.7

dioptre commented 11 years ago

Damn, I also get this on wheezy - even using the llvm 3.1 - I'm only new to Julia today, so can't help more than this at present...

(gdb) r -b sysimg.jl 
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /julia/usr/bin/julia-debug-basic -b sysimg.jl
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Warning: New definition write
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6bc92cf in jl_method_table_assoc_exact (mt=0x64e9f8, args=0x7fffffffd590, n=2) at gf.c:199
199         jl_value_t *ty = (jl_value_t*)jl_typeof(a0);
(gdb) bt
#0  0x00007ffff6bc92cf in jl_method_table_assoc_exact (mt=0x64e9f8, args=0x7fffffffd590, n=2) at gf.c:199
#1  0x00007ffff6bcc244 in jl_apply_generic (F=0x7d0420, args=0x7fffffffd590, nargs=2) at gf.c:1211
#2  0x00007ffff6bcfac3 in jl_apply (f=0x7d0420, args=0x7fffffffd590, nargs=2) at julia.h:875
#3  0x00007ffff6bd1d13 in jl_show (stream=0x0, v=0x101c070) at builtins.c:555
#4  0x00007ffff6bcb576 in check_ambiguous (ml=0x64eaa0, type=0x101c070, sig=0x7d0440, fname=0x7bd5e0) at gf.c:942
#5  0x00007ffff6bcb8dd in jl_method_list_insert (pml=0x64ea78, type=0x101c070, method=0x101c050, tvars=0x13edab8, check_amb=1) at gf.c:997
#6  0x00007ffff6bcbc01 in jl_method_table_insert (mt=0x64ea68, type=0x101c070, method=0x101c050, tvars=0x13edab8) at gf.c:1068
#7  0x00007ffff6bcccb1 in jl_add_method (gf=0x7d0480, types=0x101c070, meth=0x101c050, tvars=0x11a9898) at gf.c:1405
#8  0x00007ffff6c1ab62 in jl_method_def (name=0x7bd5e0, bp=0x7d8120, bnd=0x7d8118, argtypes=0x101c070, f=0x101c050, t=0x11a9898) at toplevel.c:394
#9  0x00007ffff56dd110 in ?? ()
#10 0x00007fffffffec70 in ?? ()
#11 0x00007fffffffd7f8 in ?? ()
#12 0x0000000000000003 in ?? ()
#13 0x00007fff00000000 in ?? ()
#14 0x00007fffffffd950 in ?? ()
#15 0x000000000101c070 in ?? ()
#16 0x000000000101c050 in ?? ()
#17 0x00000000011a9898 in ?? ()
#18 0x00007fffffffd900 in ?? ()
#19 0x00000000004018a0 in jl_show@plt ()
#20 0x0000000000000000 in ?? ()
(gdb)

Thanks if you can help out. A

staticfloat commented 11 years ago

I'm always building from scratch, Homebrew does a git reset --hard every time and cleans out the source tree, so I don't think it's a "left-over cruft" problem.

@11Kilobytes; Clang was just upgraded to 4.0, let's not rule out compiler choice just yet. @dioptre; Your issue is at least a little different from mine. (At the very least, you're crashing at a different location in code) You may want to try putting that into a different issue on chance that it won't get fixed by the eventual resolution of this issue.

pao commented 11 years ago

I meant the other way around--left-over cruft from deps could be causing builds to succeed. I'm going to try another bisect tonight with an added git clean -fdx. It will just take a lot longer.

JeffBezanson commented 11 years ago

I pushed something to get past the segfault under jl_show.

acw1251 commented 11 years ago

I ran into this problem too. I'm running Ubuntu 11.10 x64. This is the first time I've tried julia, so I didn't have an existing install. I was doing everything from scratch.

I reverted back to fadd70d41e and still had the same problem.

I then reverted back to 6f0b8900a3 from Thursday and it worked. I noticed something different when I was compiling the different versions. The versions that didn't work ended with:

...
    LINK usr/bin/julia-release-webserver
    JULIA usr/lib/julia/sys.ji
error during bootstrap

The version that worked had this in its place:

...
    LINK usr/bin/julia-release-webserver
    JULIA usr/lib/julia/sys0.ji
    JULIA usr/lib/julia/sys.ji
...

I didn't see the reference to sys0.ji anywhere in the faulty builds.

JeffBezanson commented 11 years ago

There have been some major changes and sys0.ji is no longer used. The recipe for digging into the "error during bootstrap" is:

make debug  (will end in failure, but ok)
gdb ./julia
cd base
b jl_raise  (and say yes)
r -b sysimg.jl
dmbates commented 11 years ago

With your recipe I get a failure to open the file "build_h.jl" when running base/sysimg.jl

Breakpoint 1, jl_raise (e=0x7ac8980) at task.c:525 525 jl_task_t *eh = jl_current_task->state.eh_task; (gdb) where

0 jl_raise (e=0x7ac8980) at task.c:525

1 0x00007ffff4e71268 in ?? ()

2 0x00007fffffffc3e0 in ?? ()

3 0x0000000000000003 in ?? ()

4 0x0000000000000000 in ?? ()

(gdb) c Continuing.

Breakpoint 1, jl_raise (e=0x798f050) at task.c:525 525 jl_task_t *eh = jl_current_task->state.eh_task; (gdb) where

0 jl_raise (e=0x798f050) at task.c:525

1 0x00007ffff6d951a4 in jl_errorf (fmt=0x7ffff758853b "could not open file %s") at builtins.c:48

2 0x00007ffff6dddcf7 in jl_load (fname=0x7f7670 "build_h.jl") at toplevel.c:329

3 0x00007ffff6dddd4d in jlload (str=0x7a7d10) at toplevel.c:339

4 0x00007ffff52c130c in ?? ()

5 0x00007fffffffd400 in ?? ()

6 0x00007ffff6d8df7d in jl_apply (f=0x7ffff52c130c, args=0x7fffffffd3d0, nargs=0) at julia.h:875

Backtrace stopped: frame did not save the PC (gdb)

make clean && make base/build_h.jl && make testall

succeeds

timema commented 11 years ago

"make clean && make base/build_h.jl && make testall" worked for me. It did say "Warning: replacing module Base"

acw1251 commented 11 years ago

I got the same thing as @dmbates when using aa029e3d6752dd559879d8d21e4da60048ed8e92

Breakpoint 1, jl_raise (e=0x1582c80) at task.c:525
525     jl_task_t *eh = jl_current_task->state.eh_task;
(gdb) where
#0  jl_raise (e=0x1582c80) at task.c:525
#1  0x00007ffff4f2c278 in ?? ()
#2  0x00007fffffffc250 in ?? ()
#3  0x0000000000000003 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) c
Continuing.

Breakpoint 1, jl_raise (e=0xe452f0) at task.c:525
525     jl_task_t *eh = jl_current_task->state.eh_task;
(gdb) where
#0  jl_raise (e=0xe452f0) at task.c:525
#1  0x00007ffff6d99384 in jl_errorf (fmt=0x7ffff758891b "could not open file %s") at builtins.c:48
#2  0x00007ffff6de1ed7 in jl_load (fname=0x7f3610 "build_h.jl") at toplevel.c:329
#3  0x00007ffff6de1f2d in jl_load_ (str=0x7a6d10) at toplevel.c:339
#4  0x00007ffff534f30c in ?? ()
#5  0x00007fffffffd270 in ?? ()
#6  0x00007ffff6d9215d in jl_apply (f=0x7ffff534f30c, args=0x7fffffffd240, nargs=0) at julia.h:875
Backtrace stopped: frame did not save the PC
(gdb)
JeffBezanson commented 11 years ago

Aha! That's it! One of my commits broke building of build_h.jl. This should help with the build problems we've been seeing.

JeffBezanson commented 11 years ago

And it was so broken that make clean didn't remove it, so my old build_h.jl hung around and I didn't see the problem.

acw1251 commented 11 years ago

That fixed it for me, thanks!

StefanKarpinski commented 11 years ago

Ah, nice. So it looks like af6e7803ec8017bb35c064afcbeba19225c9472c addresses this issue? It works for me in any case. @staticfloat, @dmbates, @timema, @pao, @11Kilobytes — can you guys chime in yea or nay on this fixing things?

johnmyleswhite commented 11 years ago

This (or some other change from today's commits) also solved the problem for me as well.

timema commented 11 years ago

I did a clean install with the latest and it worked for me.

staticfloat commented 11 years ago

It works sometimes, but still hangs for me every now and then.

On Mon, Jul 30, 2012 at 1:42 PM, timema < reply@reply.github.com

wrote:

I did a clean install with the latest and it worked for me.

Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/1089#issuecomment-7381393

dmbates commented 11 years ago

After af6e7803ec8017bb35c064afcbeba19225c9472c the build works fine for me. Good to be able to build again.

11Kilobytes commented 11 years ago

No dice, I deleted the julia folder cloned into it again and then when I run make the following error happens:

JULIA usr/lib/julia/sys.ji error during init: could not show value of type LoadError make[1]: * [/home/kabelo/julia/usr/lib/julia/sys.ji] Error 1 make: * [release] Error 2

staticfloat commented 11 years ago

Hmmm, actually, I am getting the same error as @11Kilobytes now. When simply running make, I get the error:

error during init:
could not show value of type LoadError

When running make clean && make debug, I get:

    JULIA usr/lib/julia/sys.ji
Stack dump:
0.      Running pass 'X86 Machine Code Emitter' on function '@anonymous'
/bin/sh: line 1: 30333 Segmentation fault: 11  /private/tmp/homebrew-julia-HEAD-ZUja/usr/bin/julia-debug-readline -b sysimg.jl

When running in gdb per @JeffBezanson's instructions above, I get: 

$ gdb ./julia 
GNU gdb 6.3.50-20050815 (Apple version gdb-1820) (Sat Jun 16 02:40:11 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...
warning: Unable to read symbols for @executable_path/../lib/libjulia-debug.dylib (file not found).

warning: Unable to read symbols from "libjulia-debug.dylib" (not yet mapped into memory).
Reading symbols for shared libraries ...... done

(gdb) cd base
Working directory /private/tmp/homebrew-julia-HEAD-ZUja/base.
(gdb) r -b sysimg.jl
Starting program: /private/tmp/homebrew-julia-HEAD-ZUja/julia -b sysimg.jl
Reading symbols for shared libraries ++++.+................................................................................................... done
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000
0x00000001000f2182 in llvm::JITDwarfEmitter::EmitDwarfTable ()

(gdb) bt
#0  0x00000001000f2182 in llvm::JITDwarfEmitter::EmitDwarfTable () at JITEventListener.h:74
#1  0x00000001000f7cc6 in (anonymous namespace)::JITEmitter::finishFunction () at JITEventListener.h:74
#2  0x0000000100127e82 in (anonymous namespace)::Emitter<llvm::JITCodeEmitter>::runOnMachineFunction () at SmallVector.h:284
#3  0x000000010031a8d7 in llvm::MachineFunctionPass::runOnFunction () at ConstantFolder.h:77
#4  0x00000001005997bb in llvm::FPPassManager::runOnFunction () at IRBuilder.h:387
#5  0x000000010059928c in llvm::FunctionPassManagerImpl::run () at IRBuilder.h:387
#6  0x00000001005991dd in llvm::FunctionPassManager::run () at IRBuilder.h:387
#7  0x00000001000eee98 in llvm::JIT::runJITOnFunctionUnlocked () at Instruction.h:174
#8  0x00000001000ef08a in llvm::JIT::getPointerToFunction () at Instruction.h:174
#9  0x0000000100050d7f in jl_generate_fptr (f=0x10104d080) at codegen.cpp:194
#10 0x000000010004eee5 in jl_apply [inlined] () at /private/tmp/homebrew-julia-HEAD-ZUja/src/julia.h:678
#11 0x000000010004eee5 in jl_trampoline (F=0x10104d080, args=0x7fff5fbfe538, nargs=0) at builtins.c:679
#12 0x000000010006cf70 in do_call (f=<value temporarily unavailable, due to optimizations>, args=<value temporarily unavailable, due to optimizations>, nargs=0, locals=<value temporarily unavailable, due to optimizations>, nl=<value temporarily unavailable, due to optimizations>) at interpreter.c:53
#13 0x000000010006bf70 in eval (e=0x10104cec0, locals=0x0, nl=0) at interpreter.c:119
#14 0x000000010006cce5 in eval_body (stmts=0x101043760, locals=0x0, nl=0, start=<value temporarily unavailable, due to optimizations>) at interpreter.c:342
#15 0x000000010006c0a4 in eval (e=<value temporarily unavailable, due to optimizations>, locals=0x0, nl=0) at interpreter.c:146
#16 0x000000010007609d in jl_toplevel_eval_flex (e=<value temporarily unavailable, due to optimizations>, fast=<value temporarily unavailable, due to optimizations>, plineno=<value temporarily unavailable, due to optimizations>) at toplevel.c:261
#17 0x000000010007657f in jl_parse_eval_all (fname=<value temporarily unavailable, due to optimizations>) at toplevel.c:308
#18 0x00000001000767bf in jl_load (fname=0x100654a7b "boot.jl") at toplevel.c:332
#19 0x000000010006fede in julia_init (imageFile=<value temporarily unavailable, due to optimizations>) at init.c:166
#20 0x0000000100001e31 in main (argc=1, argv=0x7fff5fbfeea8) at repl.c:288
dioptre commented 11 years ago

@JeffBezanson - Is fixed for me now, thanks!

11Kilobytes commented 11 years ago

Right now, I installed readline, LAPACK and BLAS using apt-get since I couldn't make them from source. Also I used Clang as the compiler. I am running Ubuntu 12.04.

This obviously isn't the only way to build Julia, that's why I am going to make a fresh install of Ubuntu 12.04 on a VM and see what it takes to build Julia.

JeffBezanson commented 11 years ago

That sounds very helpful 11K, thanks. A HOWTO based on that will be useful to a lot of people.

staticfloat commented 11 years ago

Pinging you on this, as I still have the problem described above.

JeffBezanson commented 11 years ago

Looks pretty nasty. One thing to try is uncommenting the call to "verifyFunction" at codegen.cpp:177, which might give better llvm diagnostics.

staticfloat commented 11 years ago

Same errors, even with it uncommented. (I ran a make clean && make debug)

I'm going to try building this outside of Homebrew, letting Julia download all its own libraries. If that works, I'll try to narrow down what could be causing this in the Homebrew environment. -E

On Thu, Aug 2, 2012 at 11:43 AM, Jeff Bezanson < reply@reply.github.com

wrote:

Looks pretty nasty. One thing to try is uncommenting the call to "verifyFunction" at codegen.cpp:177, which might give better llvm diagnostics.

Reply to this email directly or view it on GitHub: https://github.com/JuliaLang/julia/issues/1089#issuecomment-7464366

pedmon commented 11 years ago

I'm seeing an error on bootstrap but in a different location:

CC src/sys.o
CC src/init.o
CC src/task.o
CC src/array.o
CC src/dump.o
CC src/toplevel.o
CC src/gc.o
LINK usr/lib/libjulia-release.so
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/os_detect.jl
PERL extras/glpk_h.jl
PERL extras/julia_message_types_h.jl
CC ui/repl.o
CC ui/repl-basic.o
LINK usr/bin/julia-release-basic
CC ui/repl-readline.o

repl-readline.c: In function âinit_historyâ: repl-readline.c:73: warning: implicit declaration of function âstpcpyâ repl-readline.c:73: warning: incompatible implicit declaration of built-in function âstpcpyâ LINK usr/bin/julia-release-readline LINK usr/bin/julia-release-webserver JULIA usr/lib/julia/sys.ji could not show value of type ErrorException error during bootstrap: syntax error: error expanding macro _jl_sort_functions at sort.jl:189

make[1]: * [/n/home00/pedmon/test/julia/usr/lib/julia/sys.ji] Error 1 make: * [release] Error 2

This is building on RedHat 5.1, but I also get it on CentOS 6.2

staticfloat commented 11 years ago

@pedmon, this is likely a different issue alltogether, so I suggest you start a new thread, as this one is focused on the issues involved in building on OSX.

pedmon commented 11 years ago

Will do.

ViralBShah commented 11 years ago

Folks, I am using clang 4.0 with Xcode 4.4.1 on OS X 10.7.4, with no issues. I believe the toolchain is the same as that on OS X 10.8.

@staticfloat any updates? Did it work for you outside the homebrew environment? Since the bootstrap issue is fixed, and you have random hangs, perhaps we can have a new issue to track that, with some reproducibility? There was a clang issue with random hangs, which was fixed (#1013), but it appears to be earlier to your bug filing.

staticfloat commented 11 years ago

Hey Viral,

Yes, it did work outside of the homebrew environment. I've narrowed it down to likely be an issue with Homebrew-built FFTW; if I have Julia build her own FFTW, it works, if I use the Homebrew-supplied FFTW, it doesn't. I'm trying to get another mac homebrew user that is interested in Julia (samueljohn) to verify, but he's been pretty busy as of late. If you know anyone else that would be interested in testing this out for me, send 'em my way. As of yet I don't know that enabling the compilation of FFTW within julia works for anyone else.

staticfloat commented 11 years ago

Actually, the error has disappeared, but been replaced with a different one! This one seems to be independent of FFTW, and is much more verbose (link to gist), so that might be good.

ViralBShah commented 11 years ago

Does this error occur outside of the homebrew environment as well? Is this is on Mountain Lion as you had said? I haven't yet updated to Mountain Lion, but soon will.

@JeffBezanson can you take a look at the gist posted in the comment above?

JeffBezanson commented 11 years ago

By golly, that was useful. This was an llvm type error, which is not necessarily caught unless assertions are enabled in LLVM. Fixed.

StefanKarpinski commented 11 years ago

Nice. Once everyone confirms that this is fixed for them too, we can close this. I actually think this issue has been causing sporadic flakiness, at least on OS X, for some time now.

staticfloat commented 11 years ago

Alright, we're back to where we were before, with homebrew-provided FFTW causing compilation problems for Julia. Right now, the formula for julia causes julia to compile her own FFTW, and works that way. Still trying to see if this issue is reproducible on anyone else's machine.

EDIT: To be clear, JeffBezanson's fix got rid of the "new" error, but the "old" error persists.