Date: Sun, 05 Sep 2010 20:06:20 -0400 From: jhell <jhell@DataIX.net> To: Peter Jeremy <peterjeremy@acm.org> Cc: bf1783@gmail.com, "b. f." <bf1783@googlemail.com>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: [SOLVED]: math/blas linking to gfortran with LDADD?= -lgfortran Message-ID: <4C84307C.4070503@DataIX.net> In-Reply-To: <20100905191253.GA91710@server.vk2pj.dyndns.org> References: <AANLkTinhAPY-PEH_TegMAEx1ejHf_WoEL8KZU%2BoXGhFD@mail.gmail.com> <4C7D70CA.2070104@DataIX.net> <20100905191253.GA91710@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/05/2010 15:12, Peter Jeremy wrote: > On 2010-Aug-31 17:14:50 -0400, jhell <jhell@DataIX.net> wrote: >> 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 > > Actually, IMO, since libgfortran.so is a support library for gfortran > (much like libgcc_s.so is), it is reasonable for a user to expect > that '-lgfortran' _is_ sufficient and the current behaviour is a bug. > ports/129518 says I'm not the only person who think that. > >> -L/usr/local/lib/gcc44 would have to be passed to LDFLAGS in order for >> it to be found. > > And '-R/usr/local/lib/gcc44' as well. > > Note that a work-around has been added to bsd.gcc.mk so that ports > with USE_GCC shouldbehave correctly and the problem is limited to > using a non-base gcc outside the ports system. > Unfortunately this was caused by devel/ccache ;( or probably better said ccache attributed to finding this bug. The problem was that ccache was or is not liable for finding the lib/gccXX installs and therefore being called before, discards appropriate paths or whatnot ultimately borking the build. How I missed the problem was assuming that src.conf(5) is not used by ports(7) I had put the appropriate ccache, if then else statements in src.conf(5) to specifically keep it away from ports(7). As explained by b.f. math/blas being as old as it is uses files from /usr/src, so with that noted src.conf(5) gets pulled in and resulted in ccache being set by CC & CXX defines. The default if statement that I had in src.conf(5) was the one from the FreeBSD ccache example... Shouldn't have caught that right ??? think again... I had also set WRKDIRPREFIX=/usr/obj for ports(7)! in a if statement in make.conf(5) ARG!!! Here is the example: .if (!empty(.CURDIR:M/usr/src*) || !empty(.CURDIR:M/usr/obj*)) && !defined(NOCCACHE) Of course /usr/src is not empty here and of course /usr/obj is not empty, thats where I am compiling and of course I did not specify NOCCACHE because IMHO src.conf(5) should not be pulled into ports(7) at all. So needless to say I went the harder route of non-automation and changed that quickly to: .if defined(MY_LOCAL_DEFINE_HERE) && !defined(NOCCACHE) And now compiling graciously the ports I want with -DMY_LOCAL_DEFINE_HERE It would be real nice if someone could add NOCCACHE & WITHOUT_CCACHE to the ports .mk files so ports like math/blas can quickly override the use of ccache if the user decides to use the default example provided in local/share/doc/ccache/ccache-howto-freebsd.txt So to say the least there were multiple faulted layers here at play including me! Also math/lapack will not compile if a user has specified WITHOUT_PROFILE in there src.conf(5) specifically it wants libc_p.so.7 but a system with the above set will not have that installed. They are fixing this. Regards, -- jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C84307C.4070503>