On 7/24/2012 9:18 AM, Simon Wright wrote:
>
> Shouldn't that be LIBRARY_PATH?
>
LIBRARY_PATH will work. But the standard is to use LD_LIBRARY_PATH for
this purpose.
I used, in my notes LIBRARY_PATH to point to /usr/lib/i386-linux-gnu/
only because to find crt1.o which was due to other weird thing
about using libre gnat 2012 and not using gcc gnat. gnatmake wanted to
know where crt1.o was.
see
http://groups.google.com/group/comp.lang.ada/browse_thread/thread/f96b82f9bd22d18a
It happen that, on my box, libgfortran.so was also in /usr/lib/i386-linux-gnu/
BUT you can use LD_LIBRARY_PATH to point to where the .so are. But can't
use LD_LIBRARY_PATH to point it to where crt1.o is !
So, LIBRARY_PATH worked for building in this case.
>locate crt1.o
/usr/lib/i386-linux-gnu/crt1.o
>locate libgfortran.so
/usr/lib/i386-linux-gnu/libgfortran.so
see, they are in the same folder.
---- example -------------------------
>unset LIBRARY_PATH
>export LD_LIBRARY_PATH=/usr/lib/atlas-base/:
/usr/lib/atlas-base/atlas/:
/usr/lib/i386-linux-gnu/
>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
/usr/gnat/libexec/gcc/i686-pc-linux-gnu/4.5.4/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
gnatlink: error when calling /usr/gnat/bin/gcc
gnatmake: *** link failed.
--------------------------------------
You see the error is gnat does not find the crt1.o (not it can't find the .so libs).
Now I add LIBRARY_PATH, which is the SAME as LD_LIBRARY_PATH, and now it works,
since it uses LIBRARY_PATH to find the crt*.o, not the LD_LIBRARY_PATH
---------------------------------
>export LIBRARY_PATH=/usr/lib/i386-linux-gnu/
>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
----------------------------------
So, LIBRARY_PATH works to locate crt*.o, but also happend to locate the .so also:
-------------------------------
>unset LD_LIBRARY_PATH
>echo $LD_LIBRARY_PATH
>export LD_LIBRARY_PATH=/usr/lib/atlas-base/:/usr/lib/atlas-base/atlas/
>gnatmake cxblm.adb -largs lmfinc.o -lgfortran -lm
gnatbind -x cxblm.ali
gnatlink cxblm.ali lmfinc.o -lgfortran -lm
---------------------------------
see, now it found libgfortan.so, only becuase it happened to be
in the same folder as crt*.o. On other linux distro's this might not be the case.
> I thing the trouble is that if you create a Fortran program and compile
> it
>
> gfortran foo.f
>
> gfortran knows to include -L/usr/lib/gcc/i486-linux-gnu/4.6 (or
> equivalent) when it calls the linker; but other languages don't, so we
> have to tell them.
>
Yes, it does a shared link in the above, and must be using
ldconf to know the locations of libfortran. On my box, I get
>gfortran foo13.f90
>ldd a.out
linux-gate.so.1 => (0x0092c000)
libgfortran.so.3 => /usr/lib/i386-linux-gnu/libgfortran.so.3 (0x005fb000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x0044c000)
libquadmath.so.0 => /usr/lib/i386-linux-gnu/libquadmath.so.0 (0x00110000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0x0076a000)
/lib/ld-linux.so.2 (0x00ddd000)
might be an ldconfig thing. Not sure. It knows where all those things are.
> Much the same issue with the Ada RTS, I'd think.
>
Building things on linux can be confusing sometimes, too many
things in too many places.
--Nasser