Bug 525818

Summary: native ATLAS build fails with "No rule to make target `libptf77blas.a'"
Product: [Fedora] Fedora Reporter: Tony Nelson <tonynelson>
Component: atlasAssignee: Deji Akingunola <dakingun>
Status: CLOSED DEFERRED QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 11CC: dakingun, herrold, jfrieben
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-26 23:59:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
rpmbuild output none

Description Tony Nelson 2009-09-25 22:13:58 UTC
Description of problem:
After 3 or 4 hours, `rpmbuild -D "enable_native_atlas 1" --rebuild -ba --target i686 atlas-3.8.3-4.fc11.src.rpm` failed.  The target is an AMD Athlon; this command contains the relevent tuning flags:

gcc -o ATL_ztrsm.o -c -DL2SIZE=4194304 -I/home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/include -I/home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/..//include -I/home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_Linux -DATL_ARCH_K7 -DATL_CPUMHZ=1208 -DATL_3DNow -DATL_GAS_x8632 -DWALL -fomit-frame-pointer -mfpmath=387 -O2 -falign-loops=4 -Wa,--noexecstack -fPIC -m32 -DDCPLX /home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/..//src/blas/level3/ATL_trsm.c

Here are relevent failing lines of build output:

make libatlas.so libcblas.so libptf77blas.so libf77blas.so \
                libptcblas.so liblapack.so libclapack.so
make[1]: Entering directory `/home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/lib'
mkdir static_libs ; cd static_libs ; ar x ../libatlas.a ; cd ../
gcc -melf_i386 -shared -Wl,-soname=libatlas.so.3 \
        -o libatlas.so.3.0 static_libs/*.o -lc -lm
rm -rf static_libs
ln -s ./libatlas.so.3.0 libatlas.so.3
ln -s ./libatlas.so.3.0 libatlas.so
mkdir static_libs ; cd static_libs ; ar x ../libcblas.a ; cd ../
gcc -melf_i386 -shared -Wl,-soname=libcblas.so.3 \
           -o libcblas.so.3.0 static_libs/*.o \
           libatlas.so.3.0 -lc -lm
rm -rf static_libs
ln -s ./libcblas.so.3.0 libcblas.so.3
ln -s ./libcblas.so.3.0 libcblas.so
make[1]: *** No rule to make target `libptf77blas.a', needed by `libptf77blas.so'.  Stop.
make[1]: Leaving directory `/home/tonyn/rpmbuild/BUILD/ATLAS/i386_base/lib'
make: *** [ptshared] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.vIcs52 (%build)


Version-Release number of selected component (if applicable):


How reproducible:
At 3 or 4 hours a try, I'm not planning to do this ever again.

Steps to Reproduce:
1. rpmbuild -D "enable_native_atlas 1" --rebuild -ba --target i686 atlas-3.8.3-4.fc11.src.rpm
2.
3.
  
Actual results:
build fails

Expected results:
new RPMs

Additional info:

Comment 1 Deji Akingunola 2009-09-26 00:00:10 UTC
Do you have the full build log by any chance?

Comment 2 Tony Nelson 2009-09-26 00:41:56 UTC
No, the terminal window only has 4000 lines of scrollback, and I estimate the whole output at over 30000 lines.  The previous lines are all successful (except for normal complaints at the beginning about missing users), and I have given the results of the various initial tests.

Comment 3 Deji Akingunola 2009-09-26 01:22:10 UTC
The build failure is weird, it is likely that libf77blas was not built, so there must have been some failures during the build that didn't stop it. I'm afraid there is no way to know what happened here without the build log. Can you possibly attempt the build again, piping the output to some log file?

Comment 4 Tony Nelson 2009-09-26 15:48:32 UTC
Created attachment 362759 [details]
rpmbuild output

rpmbuild -D "enable_native_atlas 1" --rebuild -ba --target i686 atlas-3.8.3-4.fc11.src.rpm |& tee atlas_build.out

Comment 5 Joachim Frieben 2009-09-26 17:27:08 UTC
(In reply to comment #4)
Can you replace the attachment by its uncompressed version as ususal? Bugzilla does the compression on its own anyway.

Comment 6 Tony Nelson 2009-09-26 22:45:18 UTC
11 MB upload?  No thanks.  Decompress it yourself.  Geez.

Comment 7 Deji Akingunola 2009-09-26 23:59:11 UTC
The threaded libs are not failed for your native build because the pre-build configuration detected you're building on a uni-processor system. I will either find a way to detect multiple threads in the spec file and adjust it accordingly, or drop support for allowing native builds.
Your build could have proceeded much faster if atlas kernel 'architectural default' was available for your system in the source file you used. I've grab such file from upstream and enabled a -3dnow subpackage suitable for your system. You can find the binary (and the src rpm used for it) in the scratch build @ http://koji.fedoraproject.org/koji/taskinfo?taskID=1709905 .

Comment 8 Joachim Frieben 2009-09-27 10:15:56 UTC
(In reply to comment #6)
Official Bugzilla policy is to upload attachments uncompressed. Uploading a file of 11 MB was possibly a challenge maybe 10 years ago using a 56k modem, but not today, I think ..

Comment 9 Tony Nelson 2009-09-27 15:28:35 UTC
(In reply to comment #7)
> The threaded libs are not failed for your native build because the pre-build
> configuration detected you're building on a uni-processor system. I will either
> find a way to detect multiple threads in the spec file and adjust it
> accordingly, or drop support for allowing native builds.

OK.  That would be the value of "RPM_BUILD_NCPUS", right?

> Your build could have proceeded much faster if atlas kernel 'architectural
> default' was available for your system in the source file you used. I've grab
> such file from upstream and enabled a -3dnow subpackage suitable for your
> system. You can find the binary (and the src rpm used for it) in the scratch
> build @ http://koji.fedoraproject.org/koji/taskinfo?taskID=1709905 .  

It is indeed much faster to reach the point of failure.

I notice that the model sets the L1 cache size to 8 KB, but my, and I believe the majority, of Athlons have 64 KB of L1 cache.  I don't know the performance impact of this (and might not know even if the build succeeded).