Date: Tue, 31 Aug 2010 17:14:50 -0400 From: jhell <jhell@DataIX.net> To: bf1783@gmail.com Cc: "b. f." <bf1783@googlemail.com>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: math/blas linking to gfortran with LDADD?= -lgfortran Message-ID: <4C7D70CA.2070104@DataIX.net> In-Reply-To: <AANLkTinhAPY-PEH_TegMAEx1ejHf_WoEL8KZU%2BoXGhFD@mail.gmail.com> References: <AANLkTinhAPY-PEH_TegMAEx1ejHf_WoEL8KZU%2BoXGhFD@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 08/31/2010 15:06, b. f. wrote: > Would you elaborate, please? Where is a transcript showing the linking failure? > Would you mail it to me off-list? Simply -lgfortran by it self should not work. Since lib directories gcc44 gcc45 gcc46 and such are not in the standard path -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for it to be found. Off list should not be necessary. > > I don't find this to be the case. Perhaps you could provide listings for > `ldd -a /usr/local/lib/libblas.so.2`, `objdump -x > /usr/local/lib/libblas.so.2`, and > `make -C /usr/ports/math/blas -v -d l deinstall clean all`, with and > without your change, off-list? > With my change in objdump the only thing listed in objdump -x that is relevant to -lgfortran is the RPATH=/usr/local/lib/gcc44 and there is no undefined symbols. Without my change it simply will not build unless I either a) remove -lgfortran or b) add -L/usr/local/lib/gcc44 > ? USE_FORTRAN=yes ==> USE_GCC=4.4 > > You don't see any relevant undefined symbols in the blas libraries? > > With regards to your statements about math/lapack and profiling: it > has been the case for some time that this port has built and installed > these libraries by default, perhaps because this port has mainly been > used by people concerned about numerical linear algebra and concrete > measures of performance. I recently added the statement you quoted to > allow users to avoid these libraries -- it intentionally mirrors the > similar statement in the allied port math/blas, where the form is is > dictated by the use of bsd.lib.mk to build the libraries. Given the > typical use of these ports, I don't think it is unreasonable to enable > profiling libraries by default. But if you don't like it, you can now > easily opt out. Would it be possible with this to check for the existence of -lc_p before and opt out automatically while warning the user that the profiled libc was not found so profiling will be unavailable. ? Specifically this port is making a blind assumptions that profiled libraries are installed on the system it is being installed on, I do not find that to be correct. Something like this would best be handled by options that default off. gfortran44 -O -pg -c dsecndtst.f -o dsecndtst.o gfortran44 -O -pg -c tstiee.f -o tstiee.o gfortran44 -O -pg -c ilaver.f -o ilaver.o gfortran44 -O -pg -c LAPACK_version.f -o LAPACK_version.o gfortran44 -Wl,-rpath=/usr/local/lib/gcc44 -pg -o testlsame lsame.o lsametst.o /usr/local/bin/ld: cannot find -lc_p collect2: ld returned 1 exit status *** Error code 1 -- jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7D70CA.2070104>