Also, the fact that you don't have /usr/lib/libgfortran.so.3 is probably causing the issue. Try creating a symlink:
lrwxrwxrwx 1 root root 45 Feb 18 06:06 /usr/lib/libgfortran.so.3 -> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 On Thursday, February 19, 2015 at 9:11:57 AM UTC-8, Seth wrote: > > Different than what I have: > > /usr/share/doc/libgfortran3 > /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortranbegin.a > /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.a > /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.spec > /usr/lib/gcc/arm-linux-gnueabihf/4.7/libgfortran.so > /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a > /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a > /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec > /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so > /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0 > /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 > /usr/lib/libgfortran.so.3 > /home/seth/dev/julia2/julia/contrib/fixup-libgfortran.sh > /home/seth/dev/julia/julia/contrib/fixup-libgfortran.sh > /var/lib/dpkg/info/libgfortran3:armhf.md5sums > /var/lib/dpkg/info/libgfortran3:armhf.shlibs > /var/lib/dpkg/info/libgfortran3:armhf.postrm > /var/lib/dpkg/info/libgfortran3:armhf.postinst > /var/lib/dpkg/info/libgfortran3:armhf.symbols > /var/lib/dpkg/info/libgfortran3:armhf.list > > This is on raspbian: > > Linux redshift 3.18.7-v7+ #755 SMP PREEMPT Thu Feb 12 17:20:48 GMT 2015 > armv7l GNU/Linux > seth@redshift ~/dev/julia/julia $ cat /etc/issue > Raspbian GNU/Linux 7 \n \l > > > > On Thursday, February 19, 2015 at 8:29:25 AM UTC-8, Sto Forest wrote: >> >> libgfortran-4.8 does seem to be installed ( I don't think there is a >> version 4.7 in the package list ) >> >> >> Here is the result of a find for libgforrtan ... >> >> root@pithree:/opt/julia# find / -name "*libgfortran*" >> /usr/share/doc/libgfortran3 >> /usr/share/doc/libgfortran-4.8-dev >> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortranbegin.a >> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.a >> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.spec >> /usr/lib/gcc/arm-linux-gnueabihf/4.8/libgfortran.so >> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortranbegin.a >> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.a >> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.spec >> /usr/lib/gcc/arm-linux-gnueabihf/4.6/libgfortran.so >> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3.0.0 >> /usr/lib/arm-linux-gnueabihf/libgfortran.so.3 >> /opt/julia/contrib/fixup-libgfortran.sh >> /var/lib/dpkg/info/libgfortran3:armhf.md5sums >> /var/lib/dpkg/info/libgfortran3:armhf.shlibs >> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.md5sums >> /var/lib/dpkg/info/libgfortran3:armhf.postrm >> /var/lib/dpkg/info/libgfortran3:armhf.postinst >> /var/lib/dpkg/info/libgfortran-4.8-dev:armhf.list >> /var/lib/dpkg/info/libgfortran3:armhf.symbols >> /var/lib/dpkg/info/libgfortran3:armhf.list >> /var/cache/apt/archives/libgfortran-4.8-dev_4.8.2-21~rpi3rpi1_armhf.deb >> >> >> >> On Thursday, 19 February 2015 14:42:14 UTC, Viral Shah wrote: >>> >>> Try apt-get install libgfortran-dev or libgfortran-4.7-dev or something >>> similar. It is odd that it wouldn’t find libgfortran - perhaps it is a path >>> issue. >>> >>> -viral >>> >>> >>> >>> > On 19-Feb-2015, at 5:45 pm, Sto Forest <[email protected]> wrote: >>> > >>> > Latest hurdle seems to be the absence of lgfortran >>> > >>> > lapacke_ztpmqrt_work.c:54:20: warning: unused variable ‘r’ >>> [-Wunused-variable] >>> > lapacke_ztprfb_work.c: In function ‘LAPACKE_ztprfb_work’: >>> > lapacke_ztprfb_work.c:54:20: warning: unused variable ‘r’ >>> [-Wunused-variable] >>> > /usr/bin/ld: cannot find -lgfortran >>> > collect2: error: ld returned 1 exit status >>> > Makefile:120: recipe for target '../libopenblas_armv7p-r0.2.13.so' >>> failed >>> > make[3]: *** [../libopenblas_armv7p-r0.2.13.so] Error 1 >>> > Makefile:87: recipe for target 'shared' failed >>> > make[2]: *** [shared] Error 2 >>> > *** Clean the OpenBLAS build with 'make -C deps clean-openblas'. >>> Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking >>> libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were >>> errors building SandyBridge support. Both these options can also be used >>> simultaneously. *** >>> > Makefile:963: recipe for target 'openblas-v0.2.13/libopenblas.so' >>> failed >>> > make[1]: *** [openblas-v0.2.13/libopenblas.so] Error 1 >>> > Makefile:64: recipe for target 'julia-deps' failed >>> > make: *** [julia-deps] Error 2 >>> > >>> > On Saturday, 14 February 2015 20:11:04 UTC, Sto Forest wrote: >>> > Is there a way to get Julia running on the new Raspberry Pi 2, perhaps >>> under raspbian ? >>> > >>> > >>> >>>
