[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sort and -lm
From: |
Bruno Haible |
Subject: |
Re: sort and -lm |
Date: |
Sat, 07 Oct 2023 04:33:22 +0200 |
Paul Eggert wrote:
> The win for GNU sort, once I get around to fixing totalorder's -lm
> dependency
Why would that be a problem? The average run time of a 'sort' invocation
is long enough that an additional link dependency to libm shouldn't matter.
'sort' already links against libcrypto:
$ nm sort | grep ' U ' | grep -v @GLIBC
U MD5_Final@OPENSSL_3.0.0
U MD5_Init@OPENSSL_3.0.0
U MD5_Update@OPENSSL_3.0.0
If you really want to minimize the startup time, you could load the libcrypto,
needed for the option '--random', using dlopen() ? I wouldn't advocate it as
a solution on all platforms, since libltdl surely has its own set of
portability problems. But guarded by a '#ifdef __GLIBC__', why not?
Bruno
- [PATCH] totalorder, totalorderf, totalorderl: new modules, Paul Eggert, 2023/10/02
- Re: [PATCH] totalorder, totalorderf, totalorderl: new modules, Bruno Haible, 2023/10/02
- Re: [PATCH] totalorder, totalorderf, totalorderl: new modules, Paul Eggert, 2023/10/06
- Re: sort and -lm,
Bruno Haible <=
- Re: sort and -lm, Paul Eggert, 2023/10/06
- Re: sort and -lm, Pádraig Brady, 2023/10/07
- Re: sort and -lm, Paul Eggert, 2023/10/07
- Re: sort and -lm, Pádraig Brady, 2023/10/08
- sort dynamic linking overhead, Pádraig Brady, 2023/10/08
- Re: sort dynamic linking overhead, Pádraig Brady, 2023/10/09
- Re: sort and -lm, Bruno Haible, 2023/10/07
Re: [PATCH] totalorder, totalorderf, totalorderl: new modules, Bruno Haible, 2023/10/02