blas-atlas wouldn't merge on x86-macos. The reason seems to be twofold: (1) a bug in the war wrapper, and (2) problems with install_name in libraries. Reproducible: Always Actual Results: Doesn't merge. Expected Results: Should merge. Three patches will be supplied: 1. Minor fix for ${FILESDIR}/war 2. Fixes for the blas-atlas-3.8.0 ebuild. Should apply to 3.8.1 as well. 3. A patch for Make.top from the blas-atlas distribution. This is a bit large, perhaps, as much of it could be done by a 's/libtool/glibtool/' sed in the ebuild.
Created attachment 144830 [details, diff] Minor fix for ${FILESDIR}/war
Created attachment 144831 [details] Fixes for the blas-atlas-3.8.0 ebuild. Should apply to 3.8.1 as well.
Created attachment 144832 [details] A patch for Make.top from the blas-atlas distribution.
It doesn't compile for me (gcc-4.3.0) -I/Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.8.1/work/ATLAS/gentoo-build/..//include/contrib -DAdd_ -DF77_INTEGER=int -DStringSunStyle -DATL_OS_OSX -DATL_ARCH_Core2Duo -DATL_SSE3 -DATL_SSE2 -DATL_SSE1 -DATL_GAS_x8632 -O3 -pipe -march=nocona -o xdrottst drottest.o \ ATL_drot_stub.o drot.o /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.8.1/work/ATLAS/gentoo-build/lib/libtstatlas.a -lm ld: in /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.8.1/work/ATLAS/gentoo-build/lib/libtstatlas.a, file too small collect2: ld returned 1 exit status make[8]: *** [drottest] Error 1 make[8]: Leaving directory `/Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.8.1/work/ATLAS/gentoo-build/tune/blas/level1'
Strange. I cannot find any xdrottst object anywhere in my build tree. However, the problem with libtstatlas seems to be what's causing the failure. Does the (modified) war wrapper look sensible to you? At what stage do you get this error? Compiles fine here, using gcc-4.2.3. I don't have 4.3 installed, currently.
Ping! Just saw blas-atlas-3.8.2 compile fine and pass the "ebuild test" using gcc-4.2.4.
I'll have to emerge gcc-4.2.4, 4.3.1 still can't compile it here.
no luck here, just the same error as with gcc-4.3.1 like in comment #4
I don't understand what's going wrong then. Would you mind sending me a build log privately?
I just looked through the log and it seems I have these kind of errors: cc1: error: unrecognized command line option "-mcpu=ultrasparc" Not sure if that's the weird build-system probing here, or that the config is horribly messed up. I'll send you the log.
(In reply to comment #10) > I just looked through the log and it seems I have these kind of errors: > > cc1: error: unrecognized command line option "-mcpu=ultrasparc" Thanks for the log! I seem to be getting the ultrasparc errors too, now. I'll look into where those come from. However, the failure to compile seems to be unrelated. Did you apply the patches from this bug? Specifically, the war patch?
I used the ebuild as in the tree. I got lost on where when and what is/was necessary.
The war patch is necessary to fix what I think is a mistake in the archive wrapper from ${FILESDIR}. If this is not true, then there is something more complicated going on which I cannot understand. The remaining patches work around issues with Darwin libtool being different from GNU libtool. The build system uses libtool, but doesn't use the AutoTools, hence the patches in principle amount to changing libtool to glibtool. I haven't checked 3.8.2 extensively yet, but to my understanding all patches will still be necessary. And I still need to look into the ultrasparc weirdness.
war didn't call a prefix shell - fixed that I applied the make-top.patch but still: /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/src/blas/gemm/ATL_dFindCE_mm.o /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/lib/libatlas.a -lm ld: in /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/lib/libatlas.a, file too small collect2: ld returned 1 exit status make[4]: *** [xdfindCE] Error 1
alternative error: /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/src/blas/gemm/ATL_dFindCE_mm.o /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/lib/libatlas.a -lm ld: in /Volumes/Scratch/Gentoo/var/tmp/portage/sci-libs/blas-atlas-3.9.3/work/ATLAS/gentoo-build/lib/libatlas.a, archive has no table of contents collect2: ld returned 1 exit status make[4]: *** [xdfindCE] Error 1
Updated the ebuild patch for version 3.9.3 (attached). Furthermore, I think that the make-top patch needs to be corrected, if indeed libatlas is to be installed into usr/lib and the remaining libs to usr/lib/blas/atlas: change "-rpath $(RPATH)" to "-rpath $(LIBDIR)" for the libatlas.dylib rule in the make-top patch. Thus, the hunk will only change libtool to glibtool, which makes a lot of sense to me. The war issue is still troubling me: How can "$ARCHIVER $@" be a correct invocation of the archiver if the wrapper is to be invoked like "war ARCHIVER ARFLAGS LIBNAME.a OBJS.lo" and ARCHIVER=$1. That would expand to "ARCHIVER ARCHIVER ARFLAGS LIBNAME.a OBJS.lo", i.e. one ARCHIVER to many. Hence the war patch. I guess in the special case ARCHIVER=ar it works, because a and r and valid ar options, but in the general case this looks wrong to me. Compiles fine and passes tests on my x86-macos with gcc-4.3.2. Sorry, the turnaround time for this bug is so long.
Created attachment 170347 [details, diff] Fixes for the blas-atlas-3.9.3 ebuild. No need for make.top patch since blas-atlas-3.9.3.
I just applied your patch, but I still get the same as in comment #15. Quite annoying, actually. I can't get a clue out of it.
note to self: archive has no table of contents means ar was called without 's'
Sorry, can't get this fixed it seems
