From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_00,DATE_IN_PAST_24_48, FORGED_MUA_MOZILLA,REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,222ed89632aabb93 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.180.205 with SMTP id bv13mr1423789qab.8.1343315640976; Thu, 26 Jul 2012 08:14:00 -0700 (PDT) Received: by 10.66.75.39 with SMTP id z7mr1411265pav.6.1343315640824; Thu, 26 Jul 2012 08:14:00 -0700 (PDT) Path: a15ni105485768qag.0!nntp.google.com!q21no18432462qas.0!news-out.google.com!p10ni64989877pbh.1!nntp.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!border5.newsrouter.astraweb.com!border6.newsrouter.astraweb.com!news.astraweb.com!border6.a.newsrouter.astraweb.com!feed.xsnews.nl!border-1.ams.xsnews.nl!newsfeed.straub-nv.de!news.swapon.de!aioe.org!.POSTED!not-for-mail From: "Nasser M. Abbasi" Newsgroups: comp.lang.ada Subject: Re: Free AMD Core Math Library (BLAS/LAPACK) + Ada Date: Tue, 24 Jul 2012 10:19:36 -0500 Organization: Aioe.org NNTP Server Message-ID: References: <41b74e89-f112-4791-883d-236080652dbf@googlegroups.com> <34139f6f-5905-4c9e-a873-0b2445a1fccd@googlegroups.com> <87txx8yl8t.fsf@ludovic-brenta.org> <87pq7wyek7.fsf@ludovic-brenta.org> <16a6786f-6de5-49c4-90b7-a55cb238d52a@googlegroups.com> <509991f4-bcb4-45a0-84f3-b8393db64da4@googlegroups.com> <374bd898-5683-4350-8812-e3cae186ab2b@googlegroups.com> <87k3y3jxgj.fsf@ludovic-brenta.org> <23edac82-3e0e-47f5-85b7-36473e4a44ed@googlegroups.com> Reply-To: nma@12000.org NNTP-Posting-Host: 6xfnQf8NWYR0Ab23/pVebQ.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-07-24T10:19:36-05:00 List-Id: 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