Using blaslapack

[Diane Bruce]

On Mon, Oct 16, 2017 at 07:19:49AM -0700, Steve Kargl wrote:
> On Mon, Oct 16, 2017 at 02:18:01AM -0700, Yuri wrote:
> > On 10/15/17 23:20, Gleb Popov wrote:
> > > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is
...
> > Fortran implementation based on gcc is faulty due to libgcc_s.so being 
> > present in 2 versions, in base and in gcc port, making any code 
> > containing both C++ and fortran impossible to run. Your application 
> > probably can't work on FreeBSD using gcc fortran for this reason.
> > 
> 
> Huh?  I use Netlib blas/lapack compiled with gfortran on FreeBSD
> with no problem.  If you're having problems with gfortran finding
> the right libgcc_s.so, then add -rpath /usr/local/lib/gcc5 (or gcc6
> or gcc7) to yout Fortran options.

Steve is correct IFF it's a simple program, but wrong if it is a module.
What has been biting us are interpreters (e.g. python) not linked
against gfortran with the right -rpath but linked against our native libgcc.
When a binary module is loaded bad things happen if module was built
with fortran. If it is known beforehand that such modules will be loaded then
the work around is to LD_PRELOAD the gfortran libgcc or use 
LD_LIBRARY_PATH to force the gfortran libgcc to be loaded first instead
of ours. The problem is figuring out which programs load such binary
modules in the first place. There are a myriad of proper fixes possible
including bringing our libgcc up to spec.

Incidentally, flang compiled modules are one possible fix but is limited
to amd64 at the moment. Do not mix gfortran and flang
compiled modules in one program if they use I/O. Of course they use
their own I/O routines. *sigh*

> Steve

Diane (looking for that pony still)
-- 
- db at FreeBSD.org db at db.net http://www.db.net/~db