On Wed, Mar 11, 2020 at 04:12:56AM +0100, Jeremie Courreges-Anglas wrote:
> On Tue, Mar 10 2020, Theo Buehler <t...@theobuehler.org> wrote:
> > On Tue, Mar 10, 2020 at 06:35:04PM +0100, Jeremie Courreges-Anglas wrote:
> >> On Mon, Mar 09 2020, Stuart Henderson <s...@spacehopper.org> wrote:
> >> > On 2020/03/09 10:42, Theo Buehler wrote:
> >> >> On Mon, Jan 13, 2020 at 12:50:32PM +0000, Stuart Henderson wrote:
> >> >> > 2/3 through a bulk build and I see that this breaks scipy (missing
> >> >> > symbols,
> >> >> > blas/cblas-related) so needs a bit more work, but I think it's
> >> >> > generally
> >> >> > along the right lines.
> >> >>
> >> >> Not sure if this provides any useful clue, but py-numpy doesn't build at
> >> >> all on sparc64 with this diff, also due to missing blas/cblas symbols:
> >> >
> >> > You'll probably see the same on amd64 with USE_LLD=no.
> >>
> >> I managed to build scipy with no changes on amd64, so I'm not sure what
> >> the problem is on this arch (did not try with USE_LLD=No).
> >>
> >> However I took a look at the issue reported by tb on sparc64.
> >>
> >> --8<--
> >> creating /tmp/tmpKcZ0cd/tmp
> >> creating /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd
> >> compile options: '-I/usr/local/include -I/usr/include -c'
> >> cc: /tmp/tmpKcZ0cd/source.c
> >> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lcblas -o
> >> /tmp/tmpKcZ0cd/a.out
> >> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztbsv_'
> >> /usr/local/lib/libcblas.so.1.0: undefined reference to `dasum_'
> >>
> >> [...]
> >>
> >> /usr/local/lib/libcblas.so.1.0: undefined reference to `zsymm_'
> >> /usr/local/lib/libcblas.so.1.0: undefined reference to `ztrsm_'
> >> /usr/local/lib/libcblas.so.1.0: undefined reference to `sswap_'
> >> collect2: error: ld returned 1 exit status
> >> cc /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o -L/usr/local/lib -lblas -o
> >> /tmp/tmpKcZ0cd/a.out
> >> /tmp/tmpKcZ0cd/tmp/tmpKcZ0cd/source.o: In function `main':
> >> source.c:(.text.startup+0xdc): undefined reference to `cblas_ddot'
> >> collect2: error: ld returned 1 exit status
> >> -->8--
> >>
> >> libcblas.so doesn't depend on libblas.so so missing symbols are to be
> >> expected if one links with -lcblas instead of -lcblas -lblas. The
> >> second linking test fails because libblas.so doesn't provide cblas
> >> symbols.
> >
> > Thanks, this makes sense. But why does this work with ld.lld?
>
> ld.lld doesn't bother checking that all symbols in libcblas.so can be
> resolved, ld.bfd does. This means that if you link against a library
> that references a bogus symbol or lacks some library interdependency
> (DT_NEEDED) you only get a crash at run time.
>
> On amd64, using the testcase from numpy:
>
> --8<--
> russell /tmp$ cat r.c
> #include <cblas.h>
> int main(int argc, const char *argv[])
> {
> double a[4] = {1,2,3,4};
> double b[4] = {5,6,7,8};
> return cblas_ddot(4, a, 1, b, 1) > 10;
> }
> russell /tmp$ cc -I/usr/local/include r.c -L/usr/local/lib -lcblas
> russell /tmp$ ./a.out
> a.out:/usr/local/lib/libcblas.so.1.0: undefined symbol 'ddot_'
> ld.so: a.out: lazy binding failed!
> Killed
> -->8--
>
> I suspect Stuart hit a similar problem with this numpy update and scipy.
>
> Using -fuse-ld=bfd in the testcase above would result in the same errors
> as in your log.
I see. Thank you very much for your explanations.
FWIW your cblas diff is ok tb (also tested on macppc).
