On Tue, 4 Jul 2023, Mouse wrote:
I've failed to find where the second -lgcc -lgcc_eh is specified,
though (I thought there may be explanatory comments); I searched
/usr/src for -lgcc_eh and found only three hits, none of which appear
to specify the duplication. I may take a closer look sometime
In article , wrote:
>Le Sat, Jul 01, 2023 at 06:39:32PM -, Christos Zoulas a écrit :
>> In article <20230603120221.0766b60...@jupiter.mumble.net>,
>> Taylor R Campbell wrote:
>> >> Date: Sat, 3 Jun 2023 13:45:44 +0200
>> >> From: tlaro...@polynum.com
>> >>
>> >> So I suggest to add a menti
> Date: Tue, 4 Jul 2023 18:30:58 +
> From: Taylor R Campbell
>
> Other low-hanging fruit I see would be to split getenv out of the
> other environment variable operations, to get rid of locking and
> rbtree stuff. But it's diminishing returns at this point -- not clear
> the attached patchse
> Date: Fri, 30 Jun 2023 13:37:10 -0400 (EDT)
> From: Mouse
>
> sparc, my mutant 1.4T:
>
> textdatabss dec hex filename
> 12616 124 288 13028 32e4main
>
> amd64, my mutant 5.2:
>
>text data bss dec hex filename
> 152613 441
For my personal use and tail, I've arrived at:
if(argv[0] && argv[1] && (!argv[2] || !argv[3]) &&
(*argv[1] == '-' || *argv[1] == '+') &&
(*argv[1] != '-' || (*(argv[1] + 1) != 'c' && *(argv[1] + 1) != 'f'
&& *(argv[1] + 1) != 'r')) && (!argv[2] || *argv[2] != '-')) {
> No, ld reads the archive in its sequence in the arg list [...] then
> when it reaches the end of the .a file, it is done, and nothing will
> ever return to it again (the .a can be included on the link command
> line more than once - about 1 in 10,000,000 cases [statistic with 0
> supporting evide
On Tue, Jul 04, 2023 at 12:31:33PM +, RVP wrote:
> On Tue, 4 Jul 2023, RVP wrote:
>
> > I think lld(1) does things differently. I'll check this later...
> >
>
> And I was right! On Linux (what I have at hand now):
>
> ```
> $ clang -fuse-ld=lld -Wl,-Map=map.txt -static -s -o foo foo.c -L. -
Date:Tue, 4 Jul 2023 12:03:20 + (UTC)
From:RVP
Message-ID:
| It should've noticed _all_ the functions in
| the supplied archive, right?
No, ld reads the archive in its sequence in the arg list,
looks at each included .o file in the order they appear in the .
On Tue, 4 Jul 2023, RVP wrote:
I think lld(1) does things differently. I'll check this later...
And I was right! On Linux (what I have at hand now):
```
$ clang -fuse-ld=lld -Wl,-Map=map.txt -static -s -o foo foo.c -L. -lmm
$ fgrep -A3 ./libmm.a map.txt
[...]
--
224c30 2
> Can't say I understand why ld(1) behaves this way, though. (I'm
> pretty sure I ran ranlib too.) It should've noticed _all_ the
> functions in the supplied archive, right?
Not if there were no unsatisfied references to them at the time it gets
to that .a in the list. With .a archives, the uni
On Tue, 4 Jul 2023, Joerg Sonnenberger wrote:
On Tue, Jul 04, 2023 at 08:38:22AM +, RVP wrote:
b) the alloc functions in libc.a not being marked as being "weak".
This doesn't really matter at all, in fact, it is likely going to make
the situation *worse*.
You're right. And, kre@ pointe
On Tue, Jul 04, 2023 at 08:38:22AM +, RVP wrote:
> b) the alloc functions in libc.a not being marked as being "weak".
This doesn't really matter at all, in fact, it is likely going to make
the situation *worse*. The linker errors happen because you are trying
to mix and match malloc implementa
On Tue, 4 Jul 2023, RVP wrote:
So, we should:
a) collapse the newly added functions back into a single file.
Ah, looks like this patch will need a free_aligned_sized() to free
the aligned memory. Regular free(), realloc() won't work here (as-is).
-RVP
On Mon, 3 Jul 2023, Taylor R Campbell wrote:
However, if I try to link something that calls malloc or realloc with
-static -lbsdmalloc, ld objects:
$ cat null.c
#include
int main(void) { return malloc(1) != NULL; }
$ make null LDLIBS=-static\ -lbsdmalloc\ -Wl,-Map=null.map
cc -O2-o null n
14 matches
Mail list logo
