The build issue can probably be fixed with make -C src flisp-clean
See: https://github.com/JuliaLang/julia/issues/5996 Ivar kl. 15:19:41 UTC+1 søndag 16. mars 2014 skrev Nathaniel Virgo følgende: > > Pkg.installed("Images") gives me v"0.2.31". > > I’m using a git checkout from a couple of weeks ago. It seems the current > version isn’t building for me - I’ll try again next week some time. > > In case it helps, the output from make is as follows: > > $ make > Submodule path 'deps/libuv': checked out > '6649b84058e82f52adbc1a98f0b94b8aff8c467d' > Submodule path 'deps/openlibm': checked out > 'e9c0ba7ad6d19fd0e2faf065f428512bf343869d' > Submodule path 'doc/juliadoc': checked out > '88cb64ff33f25d50244c337cd3c865392a77400a' > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > /Users/ndv21/Documents/src/julia/deps/libuv/missing: Unknown > `--is-lightweight' option > Try `/Users/ndv21/Documents/src/julia/deps/libuv/missing --help' for more > information > configure: WARNING: 'missing' script is too old or missing > checking for a thread-safe mkdir -p... ./install-sh -c -d > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking build system type... x86_64-apple-darwin12.5.0 > checking host system type... x86_64-apple-darwin12.5.0 > checking for gcc... clang -mmacosx-version-min=10.6 > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether clang -mmacosx-version-min=10.6 accepts -g... yes > checking for clang -mmacosx-version-min=10.6 option to accept ISO C89... > none needed > checking whether clang -mmacosx-version-min=10.6 understands -c and -o > together... yes > checking for style of include used by make... GNU > checking dependency style of clang -mmacosx-version-min=10.6... gcc3 > checking for ar... ar > checking the archiver (ar) interface... ar > checking whether make supports nested variables... (cached) yes > checking how to print strings... printf > checking for a sed that does not truncate output... /opt/local/bin/gsed > checking for grep that handles long lines and -e... /opt/local/bin/grep > checking for egrep... /opt/local/bin/grep -E > checking for fgrep... /opt/local/bin/grep -F > checking for ld used by clang -mmacosx-version-min=10.6... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... no > checking for BSD- or MS-compatible name lister (nm)... /opt/local/bin/nm > checking the name lister (/opt/local/bin/nm) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... 196608 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... yes > checking how to convert x86_64-apple-darwin12.5.0 file names to > x86_64-apple-darwin12.5.0 format... func_convert_file_noop > checking how to convert x86_64-apple-darwin12.5.0 file names to toolchain > format... func_convert_file_noop > checking for /usr/bin/ld option to reload object files... -r > checking for objdump... no > checking how to recognize dependent libraries... pass_all > checking for dlltool... no > checking how to associate runtime and link libraries... printf %s\n > checking for archiver @FILE support... no > checking for strip... strip > checking for ranlib... ranlib > checking command to parse /opt/local/bin/nm output from clang > -mmacosx-version-min=10.6 object... ok > checking for sysroot... no > checking for mt... no > checking if : is a manifest tool... no > checking for dsymutil... dsymutil > checking for nmedit... nmedit > checking for lipo... lipo > checking for otool... otool > checking for otool64... no > checking for -single_module linker flag... yes > checking for -exported_symbols_list linker flag... yes > checking for -force_load linker flag... yes > checking how to run the C preprocessor... clang -mmacosx-version-min=10.6 -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking for dlfcn.h... yes > checking for objdir... .libs > checking if clang -mmacosx-version-min=10.6 supports -fno-rtti > -fno-exceptions... yes > checking for clang -mmacosx-version-min=10.6 option to produce PIC... > -fno-common -DPIC > checking if clang -mmacosx-version-min=10.6 PIC flag -fno-common -DPIC > works... yes > checking if clang -mmacosx-version-min=10.6 static flag -static works... no > checking if clang -mmacosx-version-min=10.6 supports -c -o file.o... yes > checking if clang -mmacosx-version-min=10.6 supports -c -o file.o... > (cached) yes > checking whether the clang -mmacosx-version-min=10.6 linker (/usr/bin/ld) > supports shared libraries... yes > checking dynamic linker characteristics... darwin12.5.0 dyld > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking for dlopen in -ldl... yes > checking for kstat_lookup in -lkstat... no > checking for kvm_open in -lkvm... no > checking for gethostbyname in -lnsl... no > checking for perfstat_cpu in -lperfstat... no > checking for pthread_mutex_init in -lpthread... yes > checking for clock_gettime in -lrt... no > checking for sendfile in -lsendfile... no > checking for socket in -lsocket... no > checking for special C compiler options needed for large files... no > checking for _FILE_OFFSET_BITS value needed for large files... no > checking for dtrace... dtrace > checking if dtrace works... yes > checking if dtrace should instrument object files... no > checking for pkg-config... yes > checking that generated files are newer than configure... done > configure: creating ./config.status > config.status: creating libuv.pc > config.status: creating Makefile > config.status: executing depfiles commands > config.status: executing libtool commands > /bin/sh ./config.status > config.status: creating libuv.pc > config.status: creating Makefile > config.status: executing depfiles commands > config.status: executing libtool commands > CC src/unix/libuv_la-process.lo > CC src/unix/libuv_la-darwin-proctitle.lo > CCLD libuv.la > ./install-sh -c -d '/Users/ndv21/Documents/src/julia/usr/lib' > /bin/sh ./libtool --mode=install /usr/bin/install -c libuv.la > '/Users/ndv21/Documents/src/julia/usr/lib' > libtool: install: /usr/bin/install -c .libs/libuv.11.dylib > /Users/ndv21/Documents/src/julia/usr/lib/libuv.11.dylib > libtool: install: (cd /Users/ndv21/Documents/src/julia/usr/lib && { ln -s -f > libuv.11.dylib libuv.dylib || { rm -f libuv.dylib && ln -s libuv.11.dylib > libuv.dylib; }; }) > libtool: install: /usr/bin/install -c .libs/libuv.lai > /Users/ndv21/Documents/src/julia/usr/lib/libuv.la > libtool: install: /usr/bin/install -c .libs/libuv.a > /Users/ndv21/Documents/src/julia/usr/lib/libuv.a > libtool: install: chmod 644 /Users/ndv21/Documents/src/julia/usr/lib/libuv.a > libtool: install: ranlib /Users/ndv21/Documents/src/julia/usr/lib/libuv.a > ./install-sh -c -d '/Users/ndv21/Documents/src/julia/usr/include' > /usr/bin/install -c -m 644 include/uv.h include/uv-errno.h > include/uv-version.h include/uv-unix.h include/uv-darwin.h > '/Users/ndv21/Documents/src/julia/usr/include' > ./install-sh -c -d '/Users/ndv21/Documents/src/julia/usr/lib/pkgconfig' > /usr/bin/install -c -m 644 libuv.pc > '/Users/ndv21/Documents/src/julia/usr/lib/pkgconfig' > CC src/jltypes.o > CC src/gf.o > CC src/support/hashing.o > CC src/support/timefuncs.o > CC src/support/ptrhash.o > CC src/support/operators.o > CC src/support/utf8.o > CC src/support/ios.o > CC src/support/htable.o > CC src/support/bitvector.o > CC src/support/int2str.o > CC src/support/libsupportinit.o > CC src/support/arraylist.o > CC src/support/strtod.o > LINK src/support/libsupport.a > CC src/flisp/flisp.o > CC src/flisp/julia_extensions.o > LINK src/flisp/libflisp.a > CC src/flisp/flisp > arg-error: io.tostring!: requires memory stream > in file unittest.lsp > #0 fatal error: > (arg-error "io.tostring!: requires memory stream") > make[3]: *** [flisp] Error 1 > make[2]: *** [flisp/libflisp.a] Error 2 > make[1]: *** [julia-release] Error 2 > make: *** [release] Error 2 > > Best regards, > Nathaniel > > > On 16 March 2014 23:06, Tim Holy <[email protected] <javascript:>> wrote: > >> That looks like the same error you reported in an earlier message in this >> thread. Can you check which version of Images you have? >> >> julia> Pkg.installed("Images") >> v"0.2.31" >> >> The change relevant for your case was to simply add a "const" declaration >> to >> one line of code: >> >> https://github.com/timholy/Images.jl/blob/master/src/ioformats/libmagickwand.jl#L29 >> >> If somehow there's a version problem you can't resolve, you can test that >> directly. >> >> > Why is it trying to open ".dylib"? >> >> When it compiles the `ccall` in init(), it's appending ".dylib" and then >> issuing a `dlopen`. Since `libwand` is empty, you end up with a complete >> path >> name of ".dylib". >> >> However, it goes much deeper. Superficially, it looks like this should >> not be a >> problem: since `have_imagemagick` is false, you might think that `ccall` >> would >> never run, so why is the error being triggered? It turns out that `ccall` >> is a >> bit of a special case: all the underlying work to load the library >> happens at >> compile-time, not at run-time. So if julia doesn't know the value of >> `have_imagemagick` in advance, it still has to go about compiling that >> `ccall`, and so you still get the error even though you'll never actually >> run >> the `ccall`. >> >> By making `have_imagemagick` be a constant, the compiler should be able to >> know its value when it compiles `init`, and therefore it can skip that >> branch >> of the conditional altogether. If adding `const` doesn't work for you, >> then >> perhaps it's a julia version issue. I tested this by renaming the library >> (so >> `find_library` couldn't find it), and for me on Linux this works on the >> latest >> version of julia. Not sure which version you're running. >> >> --Tim >> >> On Sunday, March 16, 2014 10:24:57 PM Nathaniel Virgo wrote: >> > Many thanks! >> > >> > Now I'm getting the same weird error using Images that I was getting >> using >> > GLUT: >> > >> > julia> using Images >> > ERROR: error compiling init: error compiling init: could not load >> > module : dlopen(.dylib, 1): image not found >> > in reload_path at loading.jl:144 >> > in _require at loading.jl:59 >> > in require at loading.jl:43 >> > while loading /Users/ndv21/.julia/v0.3/Images/src/Images.jl, in >> > expression starting on line 205 >> > >> > Why is it trying to open ".dylib"? >> > >> > Unfortunately I didn't try running this before doing Pkg.update(), so I >> > don't know if it's the update that caused this, or whether it's the >> result >> > of the problem I'm having with the GLUT package. >> > >> > Best regards, >> > Nathaniel >> > >> > On 16 March 2014 22:09, Tim Holy <[email protected] <javascript:>> >> wrote: >> > > I just tagged a new version that should be smarter about how it fails >> when >> > > ImageMagick isn't installed. Pkg.update() will get it for you. >> > > >> > > --Tim >> > > >> > > On Sunday, March 16, 2014 09:08:45 PM Nathaniel Virgo wrote: >> > > > On 16 March 2014 20:07, Tim Holy <[email protected] <javascript:>> >> wrote: >> > > > >> > > > Hi Nathaniel, >> > > > >> > > > > On Saturday, March 15, 2014 11:42:42 PM Nathaniel Virgo wrote: >> > > > > > Although the Homebrew issue is apparently fixed, I still get the >> > > > > > following error. >> > > > > >> > > > > I just don't know enough about Homebrew to be able to advise you >> here. >> > > > >> > > > No problem! As a newcomer, it wasn't obvious to me whether the >> error was >> > > > coming from Homebrew rather than anything else. >> > > > >> > > > Run those diagnostic commands _after_ you get this error---the whole >> > > >> > > point >> > > >> > > > > is >> > > > > to see the variable settings that contributed to this problem. >> > > > >> > > > I see. Sorry, I assumed I wouldn't be able to run the other >> commands if >> > > >> > > the >> > > >> > > > first failed. Here is the output: >> > > > >> > > > julia> Images.LibMagick.have_imagemagick >> > > > false >> > > > >> > > > julia> Images.LibMagick.libwand >> > > > "" >> > > > >> > > > I have to say that your experience here makes me think Images needs >> to >> > > > be >> > > > >> > > > > split into several parts, so that binary dependencies do not get >> in >> > > > > the >> > > > > way of >> > > > > people who just want to use it for its algorithms. Sadly, I'm >> just not >> > > > > sure >> > > > > I'll have time to get to that in the next week or two. >> > > > >> > > > That sounds like it would make sense once you have the time. (I'm >> not in >> > > >> > > a >> > > >> > > > hurry personally.) >> > > > >> > > > Nathaniel >> > > > > -- > Nathaniel Virgo > http://nathanielvirgo.com >
