Unstable vs testing: Atlas/blas problem -- ld.so patch dropped?
[ resending, I had mistyped the list address ]
On Sat, Nov 15, 2003 at 09:51:22PM -0500, Camm Maguire wrote:
> Thanks Dirk for being so on top of this. Just wanted to remind
> everyone of the issue we faced before woody went out. Upstream libc
> had made it so that /etc/ld.so.conf could not place a directory in
> front of /usr/lib. Ben Collins put in a patch for us. Don't know if
> this is related.
Excellent point. Camm, you may be on to something!! Unstable now has a 'ds'
(== debian source) branch of libc6. I was overhearing a conversation on
#debian-devel earlier today: 'ds' is apparently a euphemism for a fork.
Maybe this patch got dropped? I'll cc the maintainer list.
Debian glibc folks: See the example below. The link directive -lblas works
on testing, but no longer on unstable. Blas is "magic" library as it can be
replaced transparently by Atlas for a vast increase in performance. Debian
now uses this in maybe a dozen packages linking with blas, and thus atlas.
As Camm points out, we made that possible by interpreting the policies ld.so
should follow in a more relaxed fashion than the overly protective upstream
developers. Could it be that this patch got lost in more recent glibc work?
Thanks, Dirk
>
> Please keep me posted.
>
> Take care,
>
> Dirk Eddelbuettel <edd@debian.org> writes:
>
> > Ok, I just figured I need to get to the bottom of this via the blas 'linked
> > but not found by ldd' angle.
> >
> > I couldn't find a bona-fide Blas example via google, so I took one from the
> > (btw very good) GNU GSL documentation as GSL also permits to swap blas for
> > vendor-blas or atlas.
> >
> > Turns out that the example also "eats" blas:
> >
> > a) in the unstable chroot:
> >
> > CHROOT edd@chibud:~/src/progs/C$ gcc -Wall -o blas_sgemm_gsl blas_sgemm_gsl.c -lblas
> > CHROOT edd@chibud:~/src/progs/C$ ldd blas_sgemm_gsl
> > libc.so.6 => /lib/libc.so.6 (0x40021000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > CHROOT edd@chibud:~/src/progs/C$
> >
> > b) in testing
> >
> > edd@chibud:~/src/progs/C> gcc -Wall -o blas_sgemm_gsl blas_sgemm_gsl.c -lblas
> > edd@chibud:~/src/progs/C> ldd blas_sgemm_gsl
> > libblas.so.2 => /usr/lib/3dnow/atlas/libblas.so.2 (0x40024000)
> > libc.so.6 => /lib/libc.so.6 (0x403af000)
> > libg2c.so.0 => /usr/lib/libg2c.so.0 (0x404dd000)
> > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> > libm.so.6 => /lib/libm.so.6 (0x404fb000)
> > edd@chibud:~/src/progs/C>
> >
> > So given that testing still behaves as you'd expect, I just re-built
> > yesterday's r-base upload --- and we're good! Depends on 'atlas2-base |
> > blas2 | blas' as it should.
> >
> > Camm: Is this worthy of a bug report? Against blas or atlas? Or against gcc?
> > I'll CC doko, our esteemed gcc maintainer, who has helped me in the past.
> > Doko: ask me offline if the context is unclear. I found last night that
> > things went astray "under cover" in the built I had just done of r-base.
> >
> > Cheers, Dirk
> >
> > --
> > Those are my principles, and if you don't like them... well, I have others.
> > -- Groucho Marx
> >
> >
> >
>
> --
> Camm Maguire camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
--
Those are my principles, and if you don't like them... well, I have others.
-- Groucho Marx
Reply to: