A couple of sanity issues: - Debuginfo packages are broken, output from gdb: warning: "/usr/lib/debug/usr/lib64/atlas/liblapack.so.3.0.debug": The separate debug info file has no debug info [Thread debugging using libthread_db enabled] warning: "/usr/lib/debug/usr/lib64/atlas/libf77blas.so.3.0.debug": The separate debug info file has no debug info warning: "/usr/lib/debug/usr/lib64/atlas/libcblas.so.3.0.debug": The separate debug info file has no debug info warning: "/usr/lib/debug/usr/lib64/atlas/libatlas.so.3.0.debug": The separate debug info file has no debug info The files are just 21B in size, so they're empty. - Optimization flags are not used (which is probably the reason to the above.) - -devel packages do not provide -static, even if they contain static libraries. - Time stamps are not preserved, use cp -p instead of cp.
(In reply to comment #0) > A couple of sanity issues: > > - Debuginfo packages are broken, output from gdb: > warning: "/usr/lib/debug/usr/lib64/atlas/liblapack.so.3.0.debug": The separate > debug info file has no debug info > [Thread debugging using libthread_db enabled] > warning: "/usr/lib/debug/usr/lib64/atlas/libf77blas.so.3.0.debug": The separate > debug info file has no debug info > warning: "/usr/lib/debug/usr/lib64/atlas/libcblas.so.3.0.debug": The separate > debug info file has no debug info > warning: "/usr/lib/debug/usr/lib64/atlas/libatlas.so.3.0.debug": The separate > debug info file has no debug info > > The files are just 21B in size, so they're empty. > > - Optimization flags are not used (which is probably the reason to the above.) > Atlas is by design built with carefully selected compiler flags for optimal performance. I've been hesitant in adding the '-g' flag in the past until I can assure myself (or can be properly assured) that it is not going to negatively affect the libraries performance. > - -devel packages do not provide -static, even if they contain static > libraries. > The static libs are packaged in the -devel subpackage because the shared libs depend on them, IIRC. > - Time stamps are not preserved, use cp -p instead of cp. How so, have you look at the spec file. I'm usually careful to use the '-p' option with cp.
(In reply to comment #1) > > - Optimization flags are not used (which is probably the reason to the above.) > > > Atlas is by design built with carefully selected compiler flags for optimal > performance. I've been hesitant in adding the '-g' flag in the past until I can > assure myself (or can be properly assured) that it is not going to negatively > affect the libraries performance. Does this package have a special permission from FesCo allowing not to use them? > > - -devel packages do not provide -static, even if they contain static > > libraries. > > > The static libs are packaged in the -devel subpackage because the shared libs > depend on them, IIRC. That sounds like a logical impossibility. If the shared, dynamic libraries have been linked against the static libraries, they themselves contain the code of the static library. That's the whole idea of static linking. And this was not the question, you just have to put a Provides: atlas-static = %{version}-%{release} to the -devel package (and for the sse -devel package Provides: atlas-sse-static = %{version}-%{release} and so on). > > - Time stamps are not preserved, use cp -p instead of cp. > How so, have you look at the spec file. I'm usually careful to use the '-p' > option with cp. Yes, I have. In %setup: cp %{SOURCE1} doc
(In reply to comment #2) > (In reply to comment #1) > > > - Optimization flags are not used (which is probably the reason to the above.) > > > > > Atlas is by design built with carefully selected compiler flags for optimal > > performance. I've been hesitant in adding the '-g' flag in the past until I can > > assure myself (or can be properly assured) that it is not going to negatively > > affect the libraries performance. > > Does this package have a special permission from FesCo allowing not to use > them? > Special permission? If you feel strongly about it, you can raise it with them. > > > - -devel packages do not provide -static, even if they contain static > > > libraries. > > > > > The static libs are packaged in the -devel subpackage because the shared libs > > depend on them, IIRC. > > That sounds like a logical impossibility. If the shared, dynamic libraries have > been linked against the static libraries, they themselves contain the code of > the static library. That's the whole idea of static linking. > > And this was not the question, you just have to put a > > Provides: atlas-static = %{version}-%{release} > to the -devel package (and for the sse -devel package Provides: > atlas-sse-static = %{version}-%{release} and so on). > What will be the use of such Provides? I think I will just create a -static subpackage and put the *.a libs there. > > > - Time stamps are not preserved, use cp -p instead of cp. > > How so, have you look at the spec file. I'm usually careful to use the '-p' > > option with cp. > > Yes, I have. In %setup: > > cp %{SOURCE1} doc Will fix.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > > - Optimization flags are not used (which is probably the reason to the above.) > > > > > > > Atlas is by design built with carefully selected compiler flags for optimal > > > performance. I've been hesitant in adding the '-g' flag in the past until I can > > > assure myself (or can be properly assured) that it is not going to negatively > > > affect the libraries performance. How does the tuning of atlas work? Does it change the optimization flags by itself..? Have you performed any benchmarks to see what the effect of using the Fedora build flags would be? You could still customize them by e.g. adding -fomit-frame-pointer -mfpmath=sse -msse to the SSE version(s). > > Does this package have a special permission from FesCo allowing not to use > > them? > > > Special permission? If you feel strongly about it, you can raise it with them. I think that's the policy. Sent a mail to packaging list. > > > > - -devel packages do not provide -static, even if they contain static > > > > libraries. > > > > > > > The static libs are packaged in the -devel subpackage because the shared libs > > > depend on them, IIRC. > > > > That sounds like a logical impossibility. If the shared, dynamic libraries have > > been linked against the static libraries, they themselves contain the code of > > the static library. That's the whole idea of static linking. > > > > And this was not the question, you just have to put a > > > > Provides: atlas-static = %{version}-%{release} > > to the -devel package (and for the sse -devel package Provides: > > atlas-sse-static = %{version}-%{release} and so on). > > > What will be the use of such Provides? I think I will just create a -static > subpackage and put the *.a libs there. OK, that's a valid option too.
In my experience, adding -g doesn't impact runtime.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > (In reply to comment #1) > > > > > - Optimization flags are not used (which is probably the reason to the above.) > > > > > > > > > Atlas is by design built with carefully selected compiler flags for optimal > > > > performance. I've been hesitant in adding the '-g' flag in the past until I can > > > > assure myself (or can be properly assured) that it is not going to negatively > > > > affect the libraries performance. > > How does the tuning of atlas work? Does it change the optimization flags by > itself..? > http://math-atlas.sourceforge.net/atlas_install/atlas_install.html#SECTION00042000000000000000
this is essentially, a dup of existing bug #501772 *** This bug has been marked as a duplicate of bug 501772 ***