Building libblas.so.3

[Jessica Jones]

Would it be possible to have the default ATLAS build create the
libblas.a and libblas.so libraries?  The easy fix is to create a dummy
libblas.so that is linked against the required ATLAS libraries,
presumably libatlas.so and lib(pt)cblas.so.  This is so that several
other projects that rely on on BLAS/LAPACK can use ATLAS without changes
to their build process.

This would be particularly useful for me as, as previously mentioned,
we're distributing (internally) a very boring generic i386 SSE3 build of
ATLAS in place of the reference BLAS and LAPACK libraries, and this
change would allow us to drop ATLAS in easily as a replacement for a lot
of scientific libraries and desktop programs that often have very badly
written build systems, making it very hard to change anything that they
do by default.

Would anyone be opposed to this change?

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

[Clint Whaley]

Jess,

>Would it be possible to have the default ATLAS build create the
>libblas.a and libblas.so libraries?  The easy fix is to create a dummy
>libblas.so that is linked against the required ATLAS libraries,
>presumably libatlas.so and lib(pt)cblas.so.  This is so that several
>other projects that rely on on BLAS/LAPACK can use ATLAS without changes
>to their build process.
>
>This would be particularly useful for me as, as previously mentioned,
>we're distributing (internally) a very boring generic i386 SSE3 build of
>ATLAS in place of the reference BLAS and LAPACK libraries, and this
>change would allow us to drop ATLAS in easily as a replacement for a lot
>of scientific libraries and desktop programs that often have very badly
>written build systems, making it very hard to change anything that they
>do by default.
>
>Would anyone be opposed to this change?

I oppose it on the ground of incompetence!  :)

Building .a's I know how to do, and make work everywhere, and the build
process is almost the same on all OS.  Building dynamic libs is different
on every machine, fragile, and when anything at all changes, seem to fail
spuriously.  I have spent a lot of effort getting ATLAS able to build the
dynamic libs as good as it presently does, and yet it presently fails
about as often as it succeeds.  Therefore, I don't see dynamic libs
being built by default anytime soon.

Now, you seem also to be suggesting combining three libs to one, which
will not work.  libcblas and libptcblas provide *the same API*, one giving
threaded and one giving serial interfaces.  If you combine them, you
will lose either the threaded or serial BLAS (depending on the order
you attempt to combine them).  You can see some of this at:
   http://math-atlas.sourceforge.net/errata.html#LINK

You could build a single blas and ptblas, but then of course you would
duplicate the huge size of the present libatlas in them if they are supposed
to be standalone.

Far from library fusion, I am planning further fission: it is very likely
I will be forced to create a libptlapack for best threaded performance.

Cheers,
Clint

**************************************************************************
** R. Clint Whaley, PhD ** Assist Prof, UTSA ** www.cs.utsa.edu/~whaley **
**************************************************************************

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel

[Jessica Jones]

On 30/10/09 15:35, Clint Whaley wrote:

> Jess,
>
>> Would it be possible to have the default ATLAS build create the
>> libblas.a and libblas.so libraries?  The easy fix is to create a dummy
>> libblas.so that is linked against the required ATLAS libraries,
>> presumably libatlas.so and lib(pt)cblas.so.  This is so that several
>> other projects that rely on on BLAS/LAPACK can use ATLAS without changes
>> to their build process.
>>
>> This would be particularly useful for me as, as previously mentioned,
>> we're distributing (internally) a very boring generic i386 SSE3 build of
>> ATLAS in place of the reference BLAS and LAPACK libraries, and this
>> change would allow us to drop ATLAS in easily as a replacement for a lot
>> of scientific libraries and desktop programs that often have very badly
>> written build systems, making it very hard to change anything that they
>> do by default.
>>
>> Would anyone be opposed to this change?
>
> I oppose it on the ground of incompetence!  :)

Damn, have you found me out?  Oh ..

>
> Building .a's I know how to do, and make work everywhere, and the build
> process is almost the same on all OS.  Building dynamic libs is different
> on every machine, fragile, and when anything at all changes, seem to fail
> spuriously.  I have spent a lot of effort getting ATLAS able to build the
> dynamic libs as good as it presently does, and yet it presently fails
> about as often as it succeeds.

I guess I'm fairly privileged here in that in my use case the target
system is always some breed of x86 or x86_64 Linux, and with the various
packaging systems specifying dependencies on particular versions of
other libraries and executables (including the compiler) is generally
quite trivial.

>  Therefore, I don't see dynamic libs being built by default anytime soon.

I don't need them to be built by default, but a specific target that
created the dummy lib would be nice.  I'm really only trying to make my
life easier here though - I can just as easily provide this target for
myself with a patch rolled into the source package.

>
> Now, you seem also to be suggesting combining three libs to one, which
> will not work.

Sorry - I was just being unclear in my notation as I intended to imply
an or with the ( ) around the pt.  I'd actually expect to use the
threaded version, rather than the unthreaded one.

>  libcblas and libptcblas provide *the same API*, one giving
> threaded and one giving serial interfaces.  If you combine them, you
> will lose either the threaded or serial BLAS (depending on the order
> you attempt to combine them).  You can see some of this at:
>    http://math-atlas.sourceforge.net/errata.html#LINK
>

I thought that was fairly obvious from the description of the ptshared
make target, but I can see how someone might be confused.

> You could build a single blas and ptblas, but then of course you would
> duplicate the huge size of the present libatlas in them if they are supposed
> to be standalone.
>
> Far from library fusion, I am planning further fission: it is very likely
> I will be forced to create a libptlapack for best threaded performance.

In that case, I should be able to get what I want from a 'dummy' library
called libblas.so.3 linked against the threaded BLAS and LAPACK
libraries and against libatlas, sort of like this:

-lptlapack -lptf77blas -lptcblas -latlas

I'll just keep the patch local since it is really probably only wanted
by me for now.

Many thanks

Jess

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Math-atlas-devel mailing list
Math-atlas-devel@...
https://lists.sourceforge.net/lists/listinfo/math-atlas-devel