[Gllug] gtk+ or Qt? (or others?)

[Nix]

On Sun, 12 May 2002, Dave Jones moaned:
> On Sun, May 12, 2002 at 03:06:04PM +0100, Nix wrote:
>  > > Case in point was luser who seemed to have every lib in system linked
>  > > against pthreads[1],
>  > 
>  > Probably `because that means everything will be threaded, and threads
>  > are k00l'; I wonder how many things that broke immediately due to the
>  > changed guarantees on, for example, signals or fork(), when
>  > multithreading. (IIRC, some of those guarantees apply as soon as you
>  > *might* use threads, i.e. as soon as you link against -lpthread...)
> 
> Something else I've not yet figured out, which I'm almost too scared to
> investigate, as it seems to be intentional.
> 
> (davej at noodles:davej)$ ldd /bin/ls
>     librt.so.1 => /lib/librt.so.1 (0x4001c000)
>     libc.so.6 => /lib/libc.so.6 (0x4002d000)
>     libpthread.so.0 => /lib/libpthread.so.0 (0x4014b000)
>     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
> 
> Yum, threaded ls. (happens on Debian, SuSE and probably other distros)

Hm, it's threaded here, too, and this is a roll-yer-own system. Nothing
special needs to be done to make this happen; you just build it.

I think that this is because of librt; librt pulls in libpthread.
What's pulling in librt? Not everything, not by a long chalk...

Hm, `LD_DEBUG=bindings ls 2>&1 | grep librt' shows nothing in librt
actually being *used*.

... ah, I see.

fileutils wants -lrt for clock_gettime(), which is used by shred(1) to
seed its random number generator, and by ls(1) as a sanity check when
files are in the future. Alas, the glibc folks put clock_*() (which
don't have any dependencies) in the same library as aio_*() (which need
threads).

But clock_gettime() is only used by ls in fairly rarely (when you ls(1)
a file and it seems to have been created *right now*) so you normally
get nothing from librt pulled in at all.

> There are a lot of sick minds at work. And most of them seem to be
> writing GNU code.

Oh yes. Look at the GNU diff options for proof of *that*. Some are
useful, some are just screwy.

(Or `ls -lD', yes, well done, now you have the problem that I18N buggers
up the ls output so Emacs can't read it, you should have read everything
in from Lisp in the first place rather than relying on ls. Sheesh.)

-- 
`There are not words enough to describe how fucked up imake is.'
                                        --- Peter da Silva

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug