Ben Hutchinson | 12 Jan 23:57 2016
Picon

Use of __stdcall question

If I create a prototype function, that includes __stdcall in it, do I need to also use the directive __stdcall where the actual function is coded? Or does the fact that it's set to __stdcall in the prototype remove the requirement of also including __stdcall where the actual function is coded?
<div><div dir="ltr">If I create a prototype function, that includes __stdcall in it, do I need to also use the directive __stdcall where the actual function is coded? Or does the fact that it's set to __stdcall in the prototype remove the requirement of also including __stdcall where the actual function is coded?<br>
</div></div>
Ben Hutchinson | 12 Jan 23:38 2016
Picon

You can use __declspec in TCC?

Can you explain a bit more of that, step by step?

Why is stdlib.h used here?

Also, I thought that to set attributes like dllexport, you needed to use __attributes__((dllexport)) directive, not __declspec (which isn't even mentioned in the TCC manual). Also, I thought that to make it stdcall, you needed to use __attributes__((stdcall)), not a standalone __stdcall. These are the "weird" things that set TCC apart from all other C compilers I thought, yet you say these C compiler standards also work in TCC?

And by the way, I think __stdcall (with 2 underscores) for setting the use of STDCALL calling convention is a Microsoft thing (as used in VC++). The official C standard for setting the use of STDCALL calling convention is actually supposed to be _stdcall (with 1 underscore). Isn't that correct?

And why use asm("zzz") as in your example? I think that sets up the compiler for compiling assembly code, not C code, meaning the function must then be written in assembly language.



Message: 3
Date: Tue, 12 Jan 2016 13:02:44 +0100
From: grischka <grishka-Mmb7MZpHnFY@public.gmane.org>
To: tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
Subject: Re: [Tinycc-devel] I got this burning question about *.def
        files and       TCC.
Message-ID: <5694EB64.8000205 <at> gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ben Hutchinson wrote: ---
> I asked it before as part of a 2 part post, but only part of that post was
> replied to. So this question is still in play:
>
> Is there a way to set your exported functions with *.def files? I notice it
> usually automatically generates a *.def file when you use the
> __attributes__((dllexport)) directive. Is there a way to get it to READ,
> rather than write, a *.def file when exporting functions from a DLL, and in
> so doing, allow the *.def file to select which functions are exported? I
> really would like to know, so that I can undecorate my stdcall functions,
> via the use of *.def files.

No.  An "asm label" can do that though:

#include <stdlib.h>
__declspec(dllexport) int __stdcall fff(int a, int b) asm("zzz");

int __stdcall fff(int a, int b)
{
     ...
}

exports "zzz" instead of "_fff <at> 8".  Thanks.




------------------------------

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


End of Tinycc-devel Digest, Vol 153, Issue 11
*********************************************

<div><div dir="ltr">
<div>
<div>Can you explain a bit more of that, step by step?<br><br>
</div>
<div>Why is stdlib.h used here?<br>
</div>
<div>
<br>Also, I thought that to set attributes like dllexport, you needed to use __attributes__((dllexport)) directive, not __declspec (which isn't even mentioned in the TCC manual). Also, I thought that to make it stdcall, you needed to use __attributes__((stdcall)), not a standalone __stdcall. These are the "weird" things that set TCC apart from all other C compilers I thought, yet you say these C compiler standards also work in TCC?<br><br>
</div>And by the way, I think __stdcall (with 2 underscores) for setting the use of STDCALL calling convention is a Microsoft thing (as used in VC++). The official C standard for setting the use of STDCALL calling convention is actually supposed to be _stdcall (with 1 underscore). Isn't that correct?<br><br>
</div>And why use asm("zzz") as in your example? I think that sets up the compiler for compiling assembly code, not C code, meaning the function must then be written in assembly language.<br><div><div><div><div class="gmail_extra">
<br><div class="gmail_quote">
<br><blockquote class="gmail_quote">
<br>
Message: 3<br>
Date: Tue, 12 Jan 2016 13:02:44 +0100<br>
From: grischka &lt;<a href="mailto:grishka@...">grishka@...</a>&gt;<br>
To: <a href="mailto:tinycc-devel@...">tinycc-devel@...</a><br>
Subject: Re: [Tinycc-devel] I got this burning question about *.def<br>
&nbsp; &nbsp; &nbsp; &nbsp; files and&nbsp; &nbsp; &nbsp; &nbsp;TCC.<br>
Message-ID: &lt;<a href="mailto:5694EB64.8000205@...">5694EB64.8000205 <at> gmx.de</a>&gt;<br>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed<br><br>
Ben Hutchinson wrote: ---<br>
&gt; I asked it before as part of a 2 part post, but only part of that post was<br>
&gt; replied to. So this question is still in play:<br>
&gt;<br>
&gt; Is there a way to set your exported functions with *.def files? I notice it<br>
&gt; usually automatically generates a *.def file when you use the<br>
&gt; __attributes__((dllexport)) directive. Is there a way to get it to READ,<br>
&gt; rather than write, a *.def file when exporting functions from a DLL, and in<br>
&gt; so doing, allow the *.def file to select which functions are exported? I<br>
&gt; really would like to know, so that I can undecorate my stdcall functions,<br>
&gt; via the use of *.def files.<br><br>
No.&nbsp; An "asm label" can do that though:<br><br>
#include &lt;stdlib.h&gt;<br>
__declspec(dllexport) int __stdcall fff(int a, int b) asm("zzz");<br><br>
int __stdcall fff(int a, int b)<br>
{<br>
&nbsp; &nbsp; &nbsp;...<br>
}<br><br>
exports "zzz" instead of "_fff <at> 8".&nbsp; Thanks.<br><br><br><br><br>
------------------------------<br><br>
_______________________________________________<br>
Tinycc-devel mailing list<br><a href="mailto:Tinycc-devel@...">Tinycc-devel@...</a><br><a href="https://lists.nongnu.org/mailman/listinfo/tinycc-devel" rel="noreferrer" target="_blank">https://lists.nongnu.org/mailman/listinfo/tinycc-devel</a><br><br><br>
End of Tinycc-devel Digest, Vol 153, Issue 11<br>
*********************************************<br>
</blockquote>
</div>
<br>
</div></div></div></div>
</div></div>
Ben Hutchinson | 12 Jan 12:01 2016
Picon

I got this burning question about *.def files and TCC.

I asked it before as part of a 2 part post, but only part of that post was replied to. So this question is still in play:

Is there a way to set your exported functions with *.def files? I notice it usually automatically generates a *.def file when you use the __attributes__((dllexport)) directive. Is there a way to get it to READ, rather than write, a *.def file when exporting functions from a DLL, and in so doing, allow the *.def file to select which functions are exported? I really would like to know, so that I can undecorate my stdcall functions, via the use of *.def files.
<div><div dir="ltr">I asked it before as part of a 2 part post, but only part of that post was replied to. So this question is still in play:<br><br>Is there a way to set your exported functions with *.def files? I notice it usually automatically generates a *.def file when you use the __attributes__((dllexport)) directive. Is there a way to get it to READ, rather than write, a *.def file when exporting functions from a DLL, and in so doing, allow the *.def file to select which functions are exported? I really would like to know, so that I can undecorate my stdcall functions, via the use of *.def files.<br>
</div></div>
Christian JULLIEN | 12 Jan 11:39 2016
Picon

RE :Re: Nevermind my previous comments. I just made an error.

Hi,

Some years ago, I've read that NO C compilers are required to continue accept K&R code.
It means K&R programs are dead and you must adapt them.

Christian


----- message d'origine -----
De : "Vincent Lefevre" <vincent-buymaDBGzMOsTnJN9+BGXg@public.gmane.org>
date mar. 12/01/2016 11:14 (GMT +01:00)
À : "tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

On 2016-01-11 20:49:53 -0700, arnold-1AriSf48csbQT0dZR+AlfA@public.gmane.org wrote:
> Vincent Lefevre <vincent-buymaDBGzMOsTnJN9+BGXg@public.gmane.org> wrote:
>
> > IMHO, nowadays, it would be better for the user if compilers reject
> ^^^^^^^^
> > implicit declaration of functions by default, since warnings can
> > easily remain unnoticed since an implicit declaration is an obvious
> > bug or at least very poor & non-standard coding.
>
> Coding styles have changed over the years. I don't disagree with you,
> but remember that there are millions of lines of C code out there,
> written who knows how long ago. Compilers have to support such
> code bases, which is why the C standard didn't disallow implicit
> declarations.

Implicit declarations dated back from K&R C, where prototypes were
not checked. Old code is not guaranteed to work with new compilers
anyway and may have security issues (which wasn't a problem in the
past). Rejecting implicit declarations would be safer in practice.
For compiling old code (which is still rather rare compared to the
usual use of compilers), a special option could be added, which the
user could choose if he doesn't want to clean up the code.

--
Vincent Lefèvre <vincent-buymaDBGzMOsTnJN9+BGXg@public.gmane.org> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<p>Hi,<br><br>Some years ago, I've read that NO C compilers are required to continue accept K&amp;R code.<br>It means K&amp;R programs are dead and you must adapt them.<br><br>Christian<br><br><br></p>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"Vincent Lefevre"</span> <span dir="lrt">&lt;vincent@...&gt;</span><br>date mar. 12/01/2016 11:14 (GMT +01:00)<br>&Agrave; : <span dir="ltr">"tinycc-devel@..."</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.<br><br>On 2016-01-11 20:49:53 -0700, arnold@... wrote:<br>&gt; Vincent Lefevre &lt;vincent@...&gt; wrote:<br>&gt; <br>&gt; &gt; IMHO, nowadays, it would be better for the user if compilers reject<br>&gt;         ^^^^^^^^<br>&gt; &gt; implicit declaration of functions by default, since warnings can<br>&gt; &gt; easily remain unnoticed since an implicit declaration is an obvious<br>&gt; &gt; bug or at least very poor &amp; non-standard coding.<br>&gt; <br>&gt; Coding styles have changed over the years. I don't disagree with you,<br>&gt; but remember that there are millions of lines of C code out there,<br>&gt; written who knows how long ago. Compilers have to support such<br>&gt; code bases, which is why the C standard didn't disallow implicit<br>&gt; declarations.<br><br>Implicit declarations dated back from K&amp;R C, where prototypes were<br>not checked. Old code is not guaranteed to work with new compilers<br>anyway and may have security issues (which wasn't a problem in the<br>past). Rejecting implicit declarations would be safer in practice.<br>For compiling old code (which is still rather rare compared to the<br>usual use of compilers), a special option could be added, which the<br>user could choose if he doesn't want to clean up the code.<br><br>-- <br>Vincent Lef&egrave;vre &lt;vincent@...&gt; - Web: &lt;https://www.vinc17.net/&gt;<br>100% accessible validated (X)HTML - Blog: &lt;https://www.vinc17.net/blog/&gt;<br>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
Ben Hutchinson | 12 Jan 09:15 2016
Picon

More questions about DLLs made with TCC

Is there a way to set your exported functions with *.def files? I notice it usually automatically generates a *.def file when you use the __attributes__((dllexport)) directive. Is there a way to get it to READ, rather than write, a *.def file when working with DLLs, and in so doing, allow the *.def file to select which functions are exported?

Is there a way to specify stdcall calling convention, other than using an __attributes__((stdcall)) directive? For example, the standard usage of C usually requires simply using _stdcall. I notice that this generates errors in TCC. Can somebody please fix that bug?
<div><div dir="ltr">
<div>Is there a way to set your exported functions with *.def files? I notice it usually automatically generates a *.def file when you use the __attributes__((dllexport)) directive. Is there a way to get it to READ, rather than write, a *.def file when working with DLLs, and in so doing, allow the *.def file to select which functions are exported?<br><br>
</div>Is there a way to specify stdcall calling convention, other than using an __attributes__((stdcall)) directive? For example, the standard usage of C usually requires simply using _stdcall. I notice that this generates errors in TCC. Can somebody please fix that bug?<br>
</div></div>
Ben Hutchinson | 12 Jan 07:19 2016
Picon

What is the name of the entry point in a TCC created DLL file?

When TCC creates an EXE, it is expecting your main function to be called _start. When you are creating a DLL file though (using the -shared linker option), what is it expecting your main function to be called? I tried _start, DllMain, _dllstart, and _dllmain. None of them worked. All of these cause TCC to generate it's own default main DLL function. None of them accept my own function as the main DLL function. Please tell me how to go about creating the making a main DLL funciton in TCC.
<div><div dir="ltr">When TCC creates an EXE, it is expecting your main function to be called _start. When you are creating a DLL file though (using the -shared linker option), what is it expecting your main function to be called? I tried _start, DllMain, _dllstart, and _dllmain. None of them worked. All of these cause TCC to generate it's own default main DLL function. None of them accept my own function as the main DLL function. Please tell me how to go about creating the making a main DLL funciton in TCC.<br>
</div></div>
Ben Hutchinson | 10 Jan 13:31 2016
Picon

And now I'm having another problem with TCC

When I try to compile this:
#include <windows.h>
int _start(void){
    unsigned char MyArray[4];
    LPDWORD BytesWritten;
    HANDLE hFile;
    hFile=CreateFile("MyFile.dat",0xC0000000,0,0,2,0,0);
    MyArray[0]=1;
    MyArray[1]=2;
    MyArray[2]=3;
    MyArray[3]=4;
    WriteFile(hFile,MyArray,4,BytesWritten,0);
    CloseHandle(hFile);
}

I get a program that crashes when I run it. When I look at the dissassembly in OllyDbg, it turns out that what's happening is that in the WriteFile line of code, it's passing the value stored in BytesWritten, rather than its memory address, even though BytesWritten has been declared with LPDWORD, and even though LPDWORD has by defined (via typedef) as a pointer. When a pointer type variable is passed it should be passing the memory address, not the value stored there, but passing the value stored there is EXACTLY what's happening. The ONLY time that the value stored at a pointer should be passed is when you prefface that pointer with an asterisk. If I have a variable declared like this:
LPDWORD MyPtr
Every time I use that pointer, including passing it as a parameter in a function as just MyPtr, it SHOULD be passing the memory address, not the value stored there. The ONLY time that it should it should be using the value stored in a pointer-type variable there is if I am using an astrisk with it, like this:
*MyPtr
As you can see from the above code sample, my pointer-type variable is being passed in such a way that it should be passing the ADDRESS to the function, NOT passing the value, yet passing the value is exactly what's happening, as I can tell by running the program in a debugger.

This is a MAJOR glitch. It's what I call a "show stopper" glitch. It is significant enough that it will prevent you from from writing any decent program in TCC. I only wish the author of this software didn't stop updating it back in 2013. There's still quite a few bugs that are still NOT FIXED.
<div><div dir="ltr">
<div>
<div>
<div>When I try to compile this:<br>#include &lt;windows.h&gt;<br>int _start(void){<br>&nbsp;&nbsp;&nbsp; unsigned char MyArray[4];<br>&nbsp;&nbsp;&nbsp; LPDWORD BytesWritten;<br>&nbsp;&nbsp;&nbsp; HANDLE hFile;<br>&nbsp;&nbsp;&nbsp; hFile=CreateFile("MyFile.dat",0xC0000000,0,0,2,0,0);<br>&nbsp;&nbsp;&nbsp; MyArray[0]=1;<br>&nbsp;&nbsp;&nbsp; MyArray[1]=2;<br>&nbsp;&nbsp;&nbsp; MyArray[2]=3;<br>&nbsp;&nbsp;&nbsp; MyArray[3]=4;<br>&nbsp;&nbsp;&nbsp; WriteFile(hFile,MyArray,4,BytesWritten,0);<br>&nbsp;&nbsp;&nbsp; CloseHandle(hFile);<br>}<br><br>
</div>I get a program that crashes when I run it. When I look at the dissassembly in OllyDbg, it turns out that what's happening is that in the WriteFile line of code, it's passing the value stored in BytesWritten, rather than its memory address, even though BytesWritten has been declared with LPDWORD, and even though LPDWORD has by defined (via typedef) as a pointer. When a pointer type variable is passed it should be passing the memory address, not the value stored there, but passing the value stored there is EXACTLY what's happening. The ONLY time that the value stored at a pointer should be passed is when you prefface that pointer with an asterisk. If I have a variable declared like this:<br>LPDWORD MyPtr<br>Every time I use that pointer, including passing it as a parameter in a function as just MyPtr, it SHOULD be passing the memory address, not the value stored there. The ONLY time that it should it should be using the value stored in a pointer-type variable there is if I am using an astrisk with it, like this:<br>*MyPtr<br>
</div>As you can see from the above code sample, my pointer-type variable is being passed in such a way that it should be passing the ADDRESS to the function, NOT passing the value, yet passing the value is exactly what's happening, as I can tell by running the program in a debugger.<br><br>
</div>This is a MAJOR glitch. It's what I call a "show stopper" glitch. It is significant enough that it will prevent you from from writing any decent program in TCC. I only wish the author of this software didn't stop updating it back in 2013. There's still quite a few bugs that are still NOT FIXED.<br>
</div></div>
Ben Hutchinson | 10 Jan 11:36 2016
Picon

Nevermind my previous comments. I just made an error.

I was working with the atan2 function, and it kept glitching all over the place. Turns out I forgot to include this line at the top of my code:
#include <math.h>
<div><div dir="ltr">
<div>I was working with the atan2 function, and it kept glitching all over the place. Turns out I forgot to include this line at the top of my code:<br>
</div>#include &lt;math.h&gt;<br>
</div></div>
Ben Hutchinson | 10 Jan 10:49 2016
Picon

Tiny CC isn't working with floating point math

When using any variable defined as "float" or "double" in C code, TCC butchers all the math. I liked TinyCC because it made VERY small executables (compared to the HUGE exe files output from GCC), but floating point math is such a basic thing, that without it the compiler is almost useless. Can you think of even one program today that we use on our computers that uses EXCLUSIVELY integer math and NO floating point math? I can't think of any. Can somebody please fix TinyCC so that I can start writing some decent programs with it? Right now it's basically just a toy compiler, good for experimenting with only the most bare-bones, basic, types of software that a person could write. And I've already played around with its integer math stuff, and am starting to get bored.
<div><div dir="ltr">When using any variable defined as "float" or "double" in C code, TCC butchers all the math. I liked TinyCC because it made VERY small executables (compared to the HUGE exe files output from GCC), but floating point math is such a basic thing, that without it the compiler is almost useless. Can you think of even one program today that we use on our computers that uses EXCLUSIVELY integer math and NO floating point math? I can't think of any. Can somebody please fix TinyCC so that I can start writing some decent programs with it? Right now it's basically just a toy compiler, good for experimenting with only the most bare-bones, basic, types of software that a person could write. And I've already played around with its integer math stuff, and am starting to get bored.<br>
</div></div>
Ben Hutchinson | 10 Jan 09:40 2016
Picon

Problem with reinterpret_cast

It doesn't work in TCC. It says that it is "undeclared", like it thinks it's a variable being used without being declared. But it's NOT a variable. It's an instruction to the compiler to treat a value of one type as if it were a different type. It's a different type of cast than normal casts, because unlike normal casts, it doesn't actually covert anything. Instead it just tells the compiler to treat the data stored at the referenced location as if it were a different type of data.
<div><div dir="ltr">It doesn't work in TCC. It says that it is "undeclared", like it thinks it's a variable being used without being declared. But it's NOT a variable. It's an instruction to the compiler to treat a value of one type as if it were a different type. It's a different type of cast than normal casts, because unlike normal casts, it doesn't actually covert anything. Instead it just tells the compiler to treat the data stored at the referenced location as if it were a different type of data.<br>
</div></div>
Dylan Cali | 9 Jan 21:02 2016
Picon
Gravatar

segfault when using tcc -run on Fedora 21 and 22

Hey guys,

tcc -run is segfaulting for me, and after inspecting the core dump the
cause is not obvious to me.  I'm not sure if this is a tinycc bug or
something specific to my system.  I'm inclined to think it's something
with tinycc, as I'm experiencing the issue on both Fedora 21 and
Fedora 22.

Here is the relevant output from make test off a fresh clone and build:

dcali-fedora (mob[release_0_9_26-611]=) ~/git/tinycc
$ make test
make: Warning: File 'config.mak' has modification time 0.031 s in the future
make -C tests test 'PROGS_CROSS=i386-tcc i386-win-tcc x86_64-win-tcc
arm-linux-fpa-tcc arm-linux-fpa-ld-tcc arm-linux-gnu-tcc
arm-linux-gnueabi-tcc arm64-tcc c67-tcc arm-win-mingw32ce-tcc'
make[1]: Entering directory '/home/dylan.cali/git/tinycc/tests'
make[1]: Warning: File '../config.mak' has modification time 0.029 s
in the future
------------ hello-exe ------------
../tcc -B.. -I.. -I.. -I../include -L.. ../examples/ex1.c -o hello ||
(../tcc -vv; exit 1) && ./hello
Hello World
------------ hello-run ------------
../tcc -B.. -I.. -I.. -I../include -L.. -run ../examples/ex1.c
Makefile:94: recipe for target 'hello-run' failed
make[1]: *** [hello-run] Segmentation fault
make[1]: Leaving directory '/home/dylan.cali/git/tinycc/tests'
Makefile:377: recipe for target 'test' failed
make: *** [test] Error 2

Inspecting the coredump gives this stack trace:

Core was generated by `../tcc -B.. -I.. -I.. -I../include -L.. -run
../examples/ex1.c'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000021da3b0 in ?? ()
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.21-8.fc22.x86_64
(gdb) bt
#0  0x00000000021da3b0 in ?? ()
#1  0x000000000041b5fc in tcc_run (s1=0x21cd010, argc=1,
argv=0x7fff0145ff30) at tccrun.c:143
#2  0x0000000000429553 in main (argc=8, argv=0x7fff0145fef8) at tcc.c:347
(gdb) up
#1  0x000000000041b5fc in tcc_run (s1=0x21cd010, argc=1,
argv=0x7fff0145ff30) at tccrun.c:143
143             ret = (*prog_main)(argc, argv);
(gdb) l
138             bound_exit();
139         } else
140     #endif
141         {
142             errno = 0; /* clean errno value */
143             ret = (*prog_main)(argc, argv);
144         }
145         return ret;
146     }
147
(gdb)

So it is segfaulting when invoking prog_main.  Any idea of the cause?

I've posted my configure and make output here:
https://gist.github.com/calid/28a6db8408ef7f8b3e75

Here is some other relevant system info, let me know if you need anything else:

$ cat /etc/system-release
Fedora release 22 (Twenty Two)

$ uname -a
Linux dcali-fedora 4.2.8-200.fc22.x86_64 #1 SMP Tue Dec 15 16:50:23
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

$ /lib64/libc.so.6
GNU C Library (GNU libc) stable release version 2.21, by Roland McGrath et al.
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 5.1.1 20150618 (Red Hat 5.1.1-4).
Available extensions:
        The C stubs add-on version 2.1.2.
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        BIND-8.2.3-T5B
        RT using linux kernel aio
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Thanks much,
Dylan


Gmane