Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #64771 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-07-06 09:04 -0700 |
| Last post | 2015-07-09 15:25 -0700 |
| Articles | 20 on this page of 146 — 28 participants |
Back to article view | Back to comp.lang.c
printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 09:04 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 17:50 +0100
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:34 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:47 +0100
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 19:53 +0100
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-06 11:57 -0700
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-06 10:53 +0100
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-06 04:21 -0700
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 10:40 +0100
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 03:07 -0700
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 15:09 +0100
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-07 12:03 +0100
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-07 12:46 +0100
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 15:24 +0100
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 15:16 +0100
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-07 17:09 +0100
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 17:47 +0100
Re: printf format specifier changes Richard Damon <Richard@Damon-Family.org> - 2015-09-07 13:29 -0400
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 12:17 +0100
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-08 10:13 -0500
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 17:09 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-08 10:08 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 19:11 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-08 12:24 -0700
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-08 14:56 -0500
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 22:18 +0100
Re: printf format specifier changes Ian Collins <ian-news@hotmail.com> - 2015-09-09 09:29 +1200
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 22:58 +0100
Re: printf format specifier changes Ian Collins <ian-news@hotmail.com> - 2015-09-09 10:32 +1200
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-08 15:57 -0700
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-08 15:12 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-08 23:45 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-08 16:36 -0700
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-08 19:17 -0500
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-09 09:56 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-09 11:33 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-09-09 20:35 +0100
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-08 14:51 -0500
Re: printf format specifier changes David Brown <david.brown@hesbynett.no> - 2015-09-08 22:41 +0200
Re: printf format specifier changes Richard Damon <Richard@Damon-Family.org> - 2015-09-07 12:03 -0400
Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-10 06:33 +0000
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-10 02:38 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-10 07:01 -0700
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-10 12:47 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-10 14:08 -0700
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-10 15:17 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-10 16:02 -0700
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-10 17:31 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-11 15:43 -0700
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-09-11 16:23 -0700
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-11 23:33 -0500
Re: printf format specifier changes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 21:44 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-12 09:02 -0700
Re: printf format specifier changes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 15:00 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-27 11:21 -0700
Re: printf format specifier changes Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-29 10:10 -0700
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:41 +0100
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-09-07 00:23 -0500
Re: printf format specifier changes "James Harris" <james.harris.1@gmail.com> - 2015-09-07 11:31 +0100
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-09-07 03:54 -0700
Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 19:44 +0100
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-06 22:14 +0100
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-06 22:43 -0500
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-06 23:01 -0700
Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-07 06:43 +0000
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 10:52 +0300
Re: printf format specifier changes Richard Heathfield <rjh@cpax.org.uk> - 2015-07-09 09:26 +0100
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:56 +0300
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-12 06:12 -0700
Re: printf format specifier changes Rosario19 <Ros@invalid.invalid> - 2015-07-07 10:22 +0200
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:10 +0100
Re: printf format specifier changes Philip Lantz <prl@canterey.us> - 2015-07-07 00:54 -0700
Re: printf format specifier changes Nobody <nobody@nowhere.invalid> - 2015-07-07 15:08 +0100
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 16:12 +0100
Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-09 10:34 +0000
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 12:25 +0100
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 13:02 +0300
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-12 11:23 +0100
Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 11:50 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 12:14 -0700
Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-07 21:52 -0500
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 20:42 -0700
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:12 +0300
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-09 05:03 -0700
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 13:10 -0500
Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-09 08:58 -0400
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 08:10 -0700
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-12 12:58 +0300
Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-12 12:57 -0400
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-12 11:14 -0700
Re: printf format specifier changes gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-12 18:26 +0000
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 13:09 +0100
Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 08:10 -0400
Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 08:12 -0500
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 08:38 -0700
Re: printf format specifier changes James Kuyper <jameskuyper@verizon.net> - 2015-07-08 12:00 -0400
Re: printf format specifier changes Les Cargill <lcargill99@comcast.com> - 2015-07-08 17:20 -0500
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:08 +0300
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 20:30 +0300
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-08 18:56 +0100
Re: printf format specifier changes gordonb.lmwiv@burditt.org (Gordon Burditt) - 2015-07-09 11:09 -0500
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 14:05 -0500
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-08 11:27 -0700
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-08 15:07 -0500
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-06 23:39 -0500
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 10:19 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:57 -0500
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-07 14:15 +0100
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:46 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 09:37 -0500
Re: printf format specifier changes Phil Carmody <pc+usenet@asdf.org> - 2015-07-09 11:24 +0300
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:55 -0500
Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 11:53 -0700
Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-09 13:48 -0700
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 17:01 -0500
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 10:59 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 07:48 -0500
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 14:30 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 10:05 -0500
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-07 23:16 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-07 20:29 -0500
Re: printf format specifier changes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-08 00:43 -0700
Re: printf format specifier changes Robert Wessel <robertwessel2@yahoo.com> - 2015-07-09 02:29 -0500
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 10:34 +0100
Re: printf format specifier changes BGB <cr88192@hotmail.com> - 2015-07-09 09:35 -0500
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-07 08:37 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 08:45 -0700
Re: printf format specifier changes supercat@casperkitty.com - 2015-09-07 08:29 -0700
Re: printf format specifier changes <william@wilbur.25thandClement.com> - 2015-07-07 12:12 -0700
Re: printf format specifier changes pooja deshpande <namitadeshpande25@gmail.com> - 2015-07-09 09:29 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:34 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 09:59 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 22:33 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:17 -0700
Re: printf format specifier changes glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-10 00:30 +0000
Re: printf format specifier changes Reinhardt Behm <rbehm@hushmail.com> - 2015-07-10 09:17 +0800
Re: printf format specifier changes David Kleinecke <dkleinecke@gmail.com> - 2015-07-09 10:02 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 10:19 -0700
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-09 21:50 +0100
Re: printf format specifier changes Keith Thompson <kst-u@mib.org> - 2015-07-09 15:05 -0700
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:09 -0700
Re: printf format specifier changes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-10 00:28 +0100
Re: printf format specifier changes raltbos@xs4all.nl (Richard Bos) - 2015-07-13 20:39 +0000
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:07 -0700
Re: printf format specifier changes Bartc <bc@freeuk.com> - 2015-07-09 23:16 +0100
Re: printf format specifier changes "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-09 15:25 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-08 17:09 +0100 |
| Message-ID | <msn142$esu$1@dont-email.me> |
| In reply to | #69912 |
On 08/09/2015 16:13, Robert Wessel wrote: > On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote: [clang] >> (** It turns out that clang has been piggy-backing onto top of whatever >> gcc has been installed. It uses the include files and library files of >> gcc; possibly even its linker. By itself, it can't even compile Hello >> World, and that's a 400MB installation!) > > > You do know that GCC doesn't have any of that stuff either Actually, no I didn't. Although people are always on about the compiler and runtime library being distinct, they are generally supplied together. The person trying to program doesn't care: usually he or she just wants to go from C sources to executable or library. For example, on Windows (forget *nix which lives in a world of its own): lccwin contains a compiler, include files, linker and library files. So does Digital Mars C. So does Pelles C. So does Tiny C. And so does every install of gcc I've ever seen. In spades. (I installed something a few days ago, which might have been Mingw64, which contains 3500 ".a" library files, and 8200 .h files. Although I'm not sure exactly what I installed as I can't make head of tail of these install/package managers. But gcc on Windows does anyway comes with huge numbers of include files and libraries. Actually, I'd quite like to know how to download a bare version of gcc!) (except > perhaps the linker, not sure where that comes from, but linkers are > historically system supplied, unlike compilers (I've just discovered I can use gcc's linker LD.EXE, a single 1.2MB executable, by itself. That solves a lot of problems, removes a 400MB dependency from one of my projects, and is a lot easier to use than via gcc where I usually haven't got a clue what it's up to.) )? Hint: glibc is > maintained by an essentially entirely independent group of people > completely. Nor is glibc necessary for GCC - Mingw, for example, uses > gcc and the MS C library. I might forget glibc, if it makes life easier to just use the MSVCRT.DLL file guaranteed to be on every Windows machine. If using LD.EXE is viable, then it's usually to have control over exactly what is linked in. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-08 10:08 -0700 |
| Message-ID | <lnd1xssus6.fsf@kst-u.example.com> |
| In reply to | #69926 |
Bartc <bc@freeuk.com> writes:
> On 08/09/2015 16:13, Robert Wessel wrote:
>> On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote:
>
> [clang]
>>> (** It turns out that clang has been piggy-backing onto top of whatever
>>> gcc has been installed. It uses the include files and library files of
>>> gcc; possibly even its linker. By itself, it can't even compile Hello
>>> World, and that's a 400MB installation!)
>>
>> You do know that GCC doesn't have any of that stuff either
>
> Actually, no I didn't.
Really? It's been mentioned here numerous times; how did you not know
that?
> Although people are always on about the compiler
> and runtime library being distinct, they are generally supplied
> together. The person trying to program doesn't care: usually he or she
> just wants to go from C sources to executable or library.
Yes, a compiler and a runtime library implementation are commonly
supplied together, because you need both of them (along with a linker,
etc.) to be able to compile and run C programs.
> For example, on Windows (forget *nix which lives in a world of its own):
>
> lccwin contains a compiler, include files, linker and library files.
>
> So does Digital Mars C.
>
> So does Pelles C.
>
> So does Tiny C.
Yes, *some* C implementations include both a compiler and a runtime
library implemented by the same group. Others do not. (I'll take your
word for it that the ones listed above do so; I'm not familiar with
them.)
> And so does every install of gcc I've ever seen. In spades.
>
> (I installed something a few days ago, which might have been Mingw64,
> which contains 3500 ".a" library files, and 8200 .h files. Although I'm
> not sure exactly what I installed as I can't make head of tail of these
> install/package managers. But gcc on Windows does anyway comes with huge
> numbers of include files and libraries.
MinGW is a C implementation that includes the gcc compiler and the
Microsoft runtime library. (I don't know whether the runtime library
is packaged along with it, or whether it depends on it already being on
the system.)
> Actually, I'd quite like to know how to download a bare version of gcc!)
Well, you could build it from source, but it's a little more
compilicated than the usual configure/make/make install sequence,
since gcc bootstraps itself during the build process.
> (except
> > perhaps the linker, not sure where that comes from, but linkers are
> > historically system supplied, unlike compilers
>
> (I've just discovered I can use gcc's linker LD.EXE, a single 1.2MB
> executable, by itself. That solves a lot of problems, removes a 400MB
> dependency from one of my projects, and is a lot easier to use than via
> gcc where I usually haven't got a clue what it's up to.)
On my Linux system, the linker (/usr/bin/ld) is provided by the
"binutils" package, which includes a number of other programs including
"ar", "as" (the assembler), "strip", et al. So there are (at least)
three different software packages (gcc, libc6, binutils) that together
make up the C implementation. And any of them could be replaced with
something else.
> )? Hint: glibc is
>> maintained by an essentially entirely independent group of people
>> completely. Nor is glibc necessary for GCC - Mingw, for example, uses
>> gcc and the MS C library.
>
> I might forget glibc, if it makes life easier to just use the MSVCRT.DLL
> file guaranteed to be on every Windows machine. If using LD.EXE is
> viable, then it's usually to have control over exactly what is linked in.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-08 19:11 +0100 |
| Message-ID | <msn89l$f9k$1@dont-email.me> |
| In reply to | #69937 |
On 08/09/2015 18:08, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 08/09/2015 16:13, Robert Wessel wrote: >>> On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote: >> >> [clang] >>>> (** It turns out that clang has been piggy-backing onto top of whatever >>>> gcc has been installed. It uses the include files and library files of >>>> gcc; possibly even its linker. By itself, it can't even compile Hello >>>> World, and that's a 400MB installation!) >>> >>> You do know that GCC doesn't have any of that stuff either >> >> Actually, no I didn't. > > Really? It's been mentioned here numerous times; how did you not know > that? No, what's been mentioned a few times, when talking about how some library function works, is that gcc and the library are separate, and the responsibility is with different groups. Not that gcc normally comes with no include files (not even stdio.h) nor any libraries. A library is not necessarily an actual library, but it can be just the means to link a application with the library proper (a set of declarations for a DLL file for example). But not even those. I'm quite interested now in how many C compilers, even substantial ones such as clang, cannot even be used to compile a Hello-World program because the basic essentials are missing. (In the case of clang, a simple Readme of what it is, what it does, what is included, what isn't included, and what is needed to start compiling C programs into executables, would not have gone amiss. I expect with a 438MB distribution they couldn't squeeze in a 1K text file!) > MinGW is a C implementation that includes the gcc compiler and the > Microsoft runtime library. clang can't get that far: "hello.c:1:10: fatal error: 'stdio.h' file not found". I can't point it to where the stdio.h is, because it doesn't exist. I used to think it was because such headers were built-in, but when it's worked in the past, it might be because it searched my file system for a gcc installation and quietly made use of gcc's files. But some good news at least: anything who's thinking of writing a C compiler (there seem to be a few at the minute), apparently only has to produce a bare compiler. Forget standard headers, libraries, linkers or anything else. No need to actually make it do anything useful! -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-08 12:24 -0700 |
| Message-ID | <lnzj0wr9x9.fsf@kst-u.example.com> |
| In reply to | #69950 |
Bartc <bc@freeuk.com> writes:
> On 08/09/2015 18:08, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 08/09/2015 16:13, Robert Wessel wrote:
>>>> On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote:
>>>
>>> [clang]
>>>>> (** It turns out that clang has been piggy-backing onto top of whatever
>>>>> gcc has been installed. It uses the include files and library files of
>>>>> gcc; possibly even its linker. By itself, it can't even compile Hello
>>>>> World, and that's a 400MB installation!)
>>>>
>>>> You do know that GCC doesn't have any of that stuff either
>>>
>>> Actually, no I didn't.
>>
>> Really? It's been mentioned here numerous times; how did you not know
>> that?
>
> No, what's been mentioned a few times, when talking about how some
> library function works, is that gcc and the library are separate, and
> the responsibility is with different groups.
Yes. Isn't that pretty much what I said?
> Not that gcc normally comes with no include files (not even stdio.h) nor
> any libraries. A library is not necessarily an actual library, but it
> can be just the means to link a application with the library proper (a
> set of declarations for a DLL file for example). But not even those.
gcc is a compiler. It's not a complete C implementation, it's one
component of a complete C implementation.
stdio.h (whether it's a C header file or something else) is also
part of a C implementation but not part of the compiler.
Installing a C implementation requires installing the compiler,
the header, the runtime library, the linker, and whatever other
components are required to make up a working implementation.
Sometimes all those components are provided as a single convenient
installation.
The dividing line between the various "components" that make up a
C implementation varies. Typically the header file stdio.h and the
library that contains the code for printf and friends are part of the
same component, but in principle they could be provided separately.
The preprocessor is usually provided by, or even integrated into,
the compiler, but again that's an arbitrary implementation detail.
lcc-win, to take one example, as I understand it, is a complete
implementation (as far as I know), but I presume that, at least in
principle, you could use a different compiler to generate code that
could use the lcc-win library.
> I'm quite interested now in how many C compilers, even substantial ones
> such as clang, cannot even be used to compile a Hello-World program
> because the basic essentials are missing.
A C compiler *by itself* typically cannot compile a hello-world
program, because if all you have is C compiler, you don't have a
complete implementation.
In principle a compiler could incorporate the standard headers
(which don't have to be physical source files), and could generate
code that doesn't depend on any library. As far as I know this is
not typically done.
> (In the case of clang, a simple Readme of what it is, what it does, what
> is included, what isn't included, and what is needed to start compiling
> C programs into executables, would not have gone amiss. I expect with a
> 438MB distribution they couldn't squeeze in a 1K text file!)
Actually it's 1257 bytes.
A Google search for "clang" led me to
http://llvm.org/releases/download.html
which includes a link to
http://llvm.org/releases/3.7.0/cfe-3.7.0.src.tar.xz
labeled "Clang source code".
Unpacking that (I presume there's a way of doing that on Windows),
I see that it includes a file at the top level called "README.txt"
which starts with:
//===------------------------------------------------------------===//
// C Language Family Front-end
//===------------------------------------------------------------===//
Welcome to Clang. This is a compiler front-end for the C family of
languages (C, C++, Objective-C, and Objective-C++) which is built as
part of the LLVM compiler infrastructure project.
(I've slightly reformatted the text).
Of course this requires understanding what a "compiler front-end" is.
If you expect a "compiler front-end" to include stdio.h, perhaps
you need something more extensive than a README.txt file to exlain
it to you.
Incidentally, the src.tar.xz file is 8.8MB, and unpacks to a 98M
directory tree. There's also a "Clang for Windows (64-bit)" .exe
installer that's 49.5MB. I don't know what you're referring to
that's 438MB.
>> MinGW is a C implementation that includes the gcc compiler and the
>> Microsoft runtime library.
>
> clang can't get that far: "hello.c:1:10: fatal error: 'stdio.h' file not
> found". I can't point it to where the stdio.h is, because it doesn't
> exist. I used to think it was because such headers were built-in, but
> when it's worked in the past, it might be because it searched my file
> system for a gcc installation and quietly made use of gcc's files.
>
> But some good news at least: anything who's thinking of writing a C
> compiler (there seem to be a few at the minute), apparently only has to
> produce a bare compiler. Forget standard headers, libraries, linkers or
> anything else. No need to actually make it do anything useful!
Right, if those other components already exist you don't need to
provide them. If you want to write a complete C implementation,
that includes the compiler, the library, the linker, and so forth.
I get the impression that you think you're making some meaningful
point. As far as I can tell, this whole discussion is about the
meaning of the word "compiler", and perhaps some confusion between a
"compiler" and an "implementation".
Some of this probably sounds a bit sarcastic. That's not my intent.
I get the impression that you're having trouble understanding some
very basic points that have been explained repeatedly. I don't
think that's actually what's going on, but I'm not sure what is.
I do understand that you're frustrated by the difficulty of
installing certain software packages on Windows.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-08 14:56 -0500 |
| Message-ID | <i7fuua9bbr3mg0qnknabeq486q90ie972p@4ax.com> |
| In reply to | #69956 |
On Tue, 08 Sep 2015 12:24:50 -0700, Keith Thompson <kst-u@mib.org> wrote: >lcc-win, to take one example, as I understand it, is a complete >implementation (as far as I know), but I presume that, at least in >principle, you could use a different compiler to generate code that >could use the lcc-win library. If my understanding is correct, lcc-win started using the MS library, and added it's own library implementation to the package later.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-08 22:18 +0100 |
| Message-ID | <msnj74$sdq$1@dont-email.me> |
| In reply to | #69956 |
On 08/09/2015 20:24, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 08/09/2015 18:08, Keith Thompson wrote: >> I'm quite interested now in how many C compilers, even substantial ones >> such as clang, cannot even be used to compile a Hello-World program >> because the basic essentials are missing. > > A C compiler *by itself* typically cannot compile a hello-world > program, because if all you have is C compiler, you don't have a > complete implementation. Don't you think that's splitting hairs a little? How many people acquire a 'compiler' and not expect it to do the whole job? >> (In the case of clang, a simple Readme of what it is, what it does, what >> is included, what isn't included, and what is needed to start compiling >> C programs into executables, would not have gone amiss. I expect with a >> 438MB distribution they couldn't squeeze in a 1K text file!) > > Actually it's 1257 bytes. That explains nothing. So Clang is a front-end, but to what? What's the output? Do I need to source my own standard headers, linker and libraries (in which case, forget it)? How do I compile hello-world with it? Is there a massive dependency on gcc which they assume everyone knows so they haven't bothered mentioning it? This is very, very basic readme stuff. > There's also a "Clang for Windows (64-bit)" .exe > installer that's 49.5MB. I don't know what you're referring to > that's 438MB. (The 49.5MB unpacks to 438MB. Not a readme file in sight.) > Some of this probably sounds a bit sarcastic. That's not my intent. > I get the impression that you're having trouble understanding some > very basic points that have been explained repeatedly. I don't > think that's actually what's going on, but I'm not sure what is. > I do understand that you're frustrated by the difficulty of > installing certain software packages on Windows. Yes. The question is, is clang a self-contained compiler that I can use to compile a hello-world program? It seems that no-one really knows, not even the people who make clang! But I'm assuming it isn't so I will drop it. I don't need yet another gcc dependency! (My gcc versions are in a mess at the moment. I think it is due to DLL dependencies, which use the current search paths, and two or more versions will get them confused. My most well-behaved compiler at the moment appears to be TinyCC; I guess less to go wrong!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-09 09:29 +1200 |
| Message-ID | <d592agFldfqU1@mid.individual.net> |
| In reply to | #69978 |
Bartc wrote: > That explains nothing. So Clang is a front-end, but to what? What's the > output? Do I need to source my own standard headers, linker and > libraries (in which case, forget it)? How can any compiler (except for an embedded cross compiler) reliably produce an executable without using the host platform headers and libraries? > (My gcc versions are in a mess at the moment. I think it is due to DLL > dependencies, which use the current search paths, and two or more > versions will get them confused. Ah, so your problem is a Windows one, not a compiler one :) > My most well-behaved compiler at the moment appears to be TinyCC; I > guess less to go wrong!) What does it use for a standard library? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-08 22:58 +0100 |
| Message-ID | <msnli8$52f$1@dont-email.me> |
| In reply to | #69979 |
On 08/09/2015 22:29, Ian Collins wrote: > Bartc wrote: > >> That explains nothing. So Clang is a front-end, but to what? What's the >> output? Do I need to source my own standard headers, linker and >> libraries (in which case, forget it)? > > How can any compiler (except for an embedded cross compiler) reliably > produce an executable without using the host platform headers and > libraries? Well, when you download a 50MB zipped file which is a '64-bit binary for Windows', then you sort of expect it to do so. >> (My gcc versions are in a mess at the moment. I think it is due to DLL >> dependencies, which use the current search paths, and two or more >> versions will get them confused. > > Ah, so your problem is a Windows one, not a compiler one :) One of them, yes! A major problem is disentangling which does 32 bits and which does 64. >> My most well-behaved compiler at the moment appears to be TinyCC; I >> guess less to go wrong!) > > What does it use for a standard library? Its one ./lib folder only contains 5 libraries. One of them clearly refers to the msvcrt library. While the one ./include directory contains stdio.h. It's very transparent, unlike mingw (which, for example, contains 7 stdio.h files, of 6 different sizes). While clang contains 0 copies of stdio.h. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-09-09 10:32 +1200 |
| Message-ID | <d5960bFldfqU2@mid.individual.net> |
| In reply to | #69982 |
Bartc wrote: > On 08/09/2015 22:29, Ian Collins wrote: >> Bartc wrote: >> >>> That explains nothing. So Clang is a front-end, but to what? What's the >>> output? Do I need to source my own standard headers, linker and >>> libraries (in which case, forget it)? >> >> How can any compiler (except for an embedded cross compiler) reliably >> produce an executable without using the host platform headers and >> libraries? > > Well, when you download a 50MB zipped file which is a '64-bit binary for > Windows', then you sort of expect it to do so. At some point, the compiler's bundled libraries have to interface with the host platform kernel, so they either have to be built against a given kernel interface or use the platform run-time. The host kernel interface may or may not be public and it may or may not come with any stability guarantees so the latter option makes more sense. >>> (My gcc versions are in a mess at the moment. I think it is due to DLL >>> dependencies, which use the current search paths, and two or more >>> versions will get them confused. >> >> Ah, so your problem is a Windows one, not a compiler one :) > > One of them, yes! A major problem is disentangling which does 32 bits > and which does 64. I must dig out my seminal paper "Windows isn't a suitable platform for software development" :) >>> My most well-behaved compiler at the moment appears to be TinyCC; I >>> guess less to go wrong!) >> >> What does it use for a standard library? > > Its one ./lib folder only contains 5 libraries. One of them clearly > refers to the msvcrt library. While the one ./include directory contains > stdio.h. > > It's very transparent, unlike mingw (which, for example, contains 7 > stdio.h files, of 6 different sizes). > > While clang contains 0 copies of stdio.h. Given that the host kernel will have been built with the platform's standard library, this dose not surprise me. Because it is the bridge between user and kernel land, the C run-time library (libC in Unix land) has a special place amongst platform libraries. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-09-08 15:57 -0700 |
| Message-ID | <742882fe-822d-43a3-9a05-d5d6cdc2857f@googlegroups.com> |
| In reply to | #69986 |
On Tuesday, September 8, 2015 at 5:32:54 PM UTC-5, Ian Collins wrote: > At some point, the compiler's bundled libraries have to interface with > the host platform kernel, so they either have to be built against a > given kernel interface or use the platform run-time. The host kernel > interface may or may not be public and it may or may not come with any > stability guarantees so the latter option makes more sense. On MS-DOS or Classic Macintosh, such interfacing was done by using "software interrupt" or "trap" instructions. C compilers for such platforms would include a runtime library that would implement functions like "fprintf" by performing things like the "%" formatting and a certain amount of file buffering themselves, and then use a software interrupt or trap instruction to ask the OS to write the appropriate data to a file. I've not really studied the way Unix handles such things in much detail, but I don't really see anything wrong with the approach used on MS-DOS or Classic Macintosh, and can't quite see how anything else could be a whole lot better; I do see a lot of ways, though, in which the Unix approach seems much clunkier.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-08 15:12 -0700 |
| Message-ID | <lnr3m8r25l.fsf@kst-u.example.com> |
| In reply to | #69978 |
Bartc <bc@freeuk.com> writes:
> On 08/09/2015 20:24, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 08/09/2015 18:08, Keith Thompson wrote:
>>> I'm quite interested now in how many C compilers, even substantial ones
>>> such as clang, cannot even be used to compile a Hello-World program
>>> because the basic essentials are missing.
>>
>> A C compiler *by itself* typically cannot compile a hello-world
>> program, because if all you have is C compiler, you don't have a
>> complete implementation.
>
> Don't you think that's splitting hairs a little? How many people acquire
> a 'compiler' and not expect it to do the whole job?
Anyone who knows what the word "compiler" means. As you should by now,
after it's been explained to you so many times. Are you being
deliberately obtuse?
>>> (In the case of clang, a simple Readme of what it is, what it does, what
>>> is included, what isn't included, and what is needed to start compiling
>>> C programs into executables, would not have gone amiss. I expect with a
>>> 438MB distribution they couldn't squeeze in a 1K text file!)
>>
>> Actually it's 1257 bytes.
>
> That explains nothing. So Clang is a front-end, but to what? What's the
> output? Do I need to source my own standard headers, linker and
> libraries (in which case, forget it)? How do I compile hello-world with
> it? Is there a massive dependency on gcc which they assume everyone
> knows so they haven't bothered mentioning it?
>
> This is very, very basic readme stuff.
It's a compiler front-end. It is not, and does not claim to be, a
full C implementation. The phrase "compiler front-end" is clear to
anyone who knows what that phrase means. If you want more details
about clang, RTFM. (I have clang on my system, and it works, but
I installed it via the Debian/Ubuntu/Linux Mint packaging system.
I'm sure has dependencies on other components that I had already
installed; I don't know the details, and they probably wouldn't
help you much anyway.)
>> There's also a "Clang for Windows (64-bit)" .exe
>> installer that's 49.5MB. I don't know what you're referring to
>> that's 438MB.
>
> (The 49.5MB unpacks to 438MB. Not a readme file in sight.)
Ok. I don't know what's in the Windows installer, so I can't say
anything meaningful about it.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-08 23:45 +0100 |
| Message-ID | <msnoac$j7a$1@dont-email.me> |
| In reply to | #69984 |
On 08/09/2015 23:12, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 08/09/2015 20:24, Keith Thompson wrote: > >> A C compiler *by itself* typically cannot compile a hello-world >>> program, because if all you have is C compiler, you don't have a >>> complete implementation. >> >> Don't you think that's splitting hairs a little? How many people acquire >> a 'compiler' and not expect it to do the whole job? > > Anyone who knows what the word "compiler" means. As you should by now, > after it's been explained to you so many times. Are you being > deliberately obtuse? I know what a compiler is. I first used one in 1976. Sometimes compilers did the whole job (of turning source code into something that could be run), sometimes it generated object files and these were combined by a linking stage. (I've also written probably a dozen, of various kinds.) But it's taken until 2015 for someone to come up with a 'compiler' that is not capable of turning source code into object code! >> This is very, very basic readme stuff. > > It's a compiler front-end. It is not, and does not claim to be, a > full C implementation. The phrase "compiler front-end" is clear to > anyone who knows what that phrase means. I'm not sure that you do. To me, 'front-end' suggests it generates intermediate code. Which means it cannot be a complete 'compiler'. Clang I believe can generate object code, but it needs a set of standard C header files to be supplied. I'm guessing however, hence a real need for basic notes to clarify. Or they could just have bundled the 10 or 20KB of files needed and be done with it. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-08 16:36 -0700 |
| Message-ID | <lnegi8qy9n.fsf@kst-u.example.com> |
| In reply to | #69989 |
Bartc <bc@freeuk.com> writes:
> On 08/09/2015 23:12, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 08/09/2015 20:24, Keith Thompson wrote:
> >
>>> A C compiler *by itself* typically cannot compile a hello-world
>>>> program, because if all you have is C compiler, you don't have a
>>>> complete implementation.
>>>
>>> Don't you think that's splitting hairs a little? How many people acquire
>>> a 'compiler' and not expect it to do the whole job?
>>
>> Anyone who knows what the word "compiler" means. As you should by now,
>> after it's been explained to you so many times. Are you being
>> deliberately obtuse?
>
> I know what a compiler is. I first used one in 1976. Sometimes compilers
> did the whole job (of turning source code into something that could be
> run), sometimes it generated object files and these were combined by a
> linking stage. (I've also written probably a dozen, of various kinds.)
>
> But it's taken until 2015 for someone to come up with a 'compiler' that
> is not capable of turning source code into object code!
You say you've installed a version of clang that choked on
`#include <stdio.h>`.
Try compiling something that doesn't use any headers, for example:
int main(void) {
int n = 42;
n ++;
}
Compile it with `clang -c filename`. You should get an object file,
probably named "filename.obj".
If you want to compile something with `#include <stdio.h>`, you'll need
something that provides stdio.h. If you want to run it, you'll need a
runtime library and a linker.
I actually would have expected the "Clang for Windows" installer from
the LLVM download page to provide that, but if it doesn't I'm not the
right person to ask about it.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-08 19:17 -0500 |
| Message-ID | <tiuuua1slde6149re84q8vnf1bli4m32o3@4ax.com> |
| In reply to | #69989 |
On Tue, 8 Sep 2015 23:45:13 +0100, Bartc <bc@freeuk.com> wrote: >On 08/09/2015 23:12, Keith Thompson wrote: >> It's a compiler front-end. It is not, and does not claim to be, a >> full C implementation. The phrase "compiler front-end" is clear to >> anyone who knows what that phrase means. > >I'm not sure that you do. To me, 'front-end' suggests it generates >intermediate code. Which means it cannot be a complete 'compiler'. > >Clang I believe can generate object code, but it needs a set of standard >C header files to be supplied. I'm guessing however, hence a real need >for basic notes to clarify. Or they could just have bundled the 10 or >20KB of files needed and be done with it. Clang is a front end for LLVM. The two together are most of a compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-09 09:56 +0100 |
| Message-ID | <msos4h$jn8$1@dont-email.me> |
| In reply to | #70010 |
On 09/09/2015 01:17, Robert Wessel wrote: > On Tue, 8 Sep 2015 23:45:13 +0100, Bartc <bc@freeuk.com> wrote: > >> On 08/09/2015 23:12, Keith Thompson wrote: >>> It's a compiler front-end. It is not, and does not claim to be, a >>> full C implementation. The phrase "compiler front-end" is clear to >>> anyone who knows what that phrase means. >> >> I'm not sure that you do. To me, 'front-end' suggests it generates >> intermediate code. Which means it cannot be a complete 'compiler'. >> >> Clang I believe can generate object code, but it needs a set of standard >> C header files to be supplied. I'm guessing however, hence a real need >> for basic notes to clarify. Or they could just have bundled the 10 or >> 20KB of files needed and be done with it. > > > Clang is a front end for LLVM. The two together are most of a > compiler. So what exactly is needed to make a full working implementation? This Windows installation was in a list of files under LLVM 3.7.0 Download. Do I need a mingw installation? Then it should say so. Do I need the rest of LLVM? Then it should say so (and where to obtain one from, as this *was* the LLVM download page after all! And what it might actually look like when I see it.). All I'm saying, is they have neglected to provide these extremely basic bits of information. (Why would they do that? Because the answers are by no means obvious. If they were, someone here would have known. Nobody seems to know for sure, they can only quote some vague, woolly facts from somewhere in the vast LLVM ecosystem.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-09 11:33 -0700 |
| Message-ID | <lnsi6nphn4.fsf@kst-u.example.com> |
| In reply to | #70027 |
Bartc <bc@freeuk.com> writes:
> On 09/09/2015 01:17, Robert Wessel wrote:
[...]
>> Clang is a front end for LLVM. The two together are most of a
>> compiler.
>
> So what exactly is needed to make a full working implementation?
>
> This Windows installation was in a list of files under LLVM 3.7.0 Download.
>
> Do I need a mingw installation? Then it should say so.
>
> Do I need the rest of LLVM? Then it should say so (and where to obtain
> one from, as this *was* the LLVM download page after all! And what it
> might actually look like when I see it.).
>
> All I'm saying, is they have neglected to provide these extremely basic
> bits of information. (Why would they do that? Because the answers are by
> no means obvious. If they were, someone here would have known. Nobody
> seems to know for sure, they can only quote some vague, woolly facts
> from somewhere in the vast LLVM ecosystem.)
I have no answers for you. If others here don't either, it's not
necessarily because the answers aren't obvious; most of us probably
just don't use Clang/LLVM under Windows. For the Linux systems
I use, installing and using Clang is easy - which means I don't
happen to know the inner workings.
However, there are plenty of support forums for LLVM. There's an
FAQ, an IRC channel, and a number of mailing lists, all linked
from llvm.org. Any of them should get you information from LLVM
experts, rather than from the C experts who hang out here.
Try asking the people who know rather than complaining to the people
who don't.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-09-09 20:35 +0100 |
| Message-ID | <msq1i1$htp$1@dont-email.me> |
| In reply to | #70061 |
On 09/09/2015 19:33, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: [clang C compiler. [Or is it the front-end of a compiler? That's still open...]] > However, there are plenty of support forums for LLVM. There's an > FAQ, an IRC channel, and a number of mailing lists, all linked > from llvm.org. Any of them should get you information from LLVM > experts, rather than from the C experts who hang out here. > > Try asking the people who know rather than complaining to the people > who don't. You think I didn't try looking for a forum? (But I rejected one called 'Clang Developers' because I thought it was for people developing clang, rather than developers using clang.) Anyway posting about it here might help lurkers who are looking for a C compiler and will now know what to avoid. Or at least won't be too surprised about it when it doesn't work. (I've dropped clang myself because I don't like the underhand way it quietly attaches itself to another compiler.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-09-08 14:51 -0500 |
| Message-ID | <nceuuadn8t0jtnlc2hr04map1o1p2dpj1m@4ax.com> |
| In reply to | #69950 |
On Tue, 8 Sep 2015 19:11:46 +0100, Bartc <bc@freeuk.com> wrote: >On 08/09/2015 18:08, Keith Thompson wrote: >> Bartc <bc@freeuk.com> writes: >>> On 08/09/2015 16:13, Robert Wessel wrote: >>>> On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote: >>> >>> [clang] >>>>> (** It turns out that clang has been piggy-backing onto top of whatever >>>>> gcc has been installed. It uses the include files and library files of >>>>> gcc; possibly even its linker. By itself, it can't even compile Hello >>>>> World, and that's a 400MB installation!) >>>> >>>> You do know that GCC doesn't have any of that stuff either >>> >>> Actually, no I didn't. >> >> Really? It's been mentioned here numerous times; how did you not know >> that? > >No, what's been mentioned a few times, when talking about how some >library function works, is that gcc and the library are separate, and >the responsibility is with different groups. > >Not that gcc normally comes with no include files (not even stdio.h) nor >any libraries. A library is not necessarily an actual library, but it >can be just the means to link a application with the library proper (a >set of declarations for a DLL file for example). But not even those. > >I'm quite interested now in how many C compilers, even substantial ones >such as clang, cannot even be used to compile a Hello-World program >because the basic essentials are missing. ICC on Windows uses MSVCRT by default, although I seem to recall there was another option. I've seen many language products on many platforms that did not include a linker (but assumed the platform supplied it). >(In the case of clang, a simple Readme of what it is, what it does, what >is included, what isn't included, and what is needed to start compiling >C programs into executables, would not have gone amiss. I expect with a >438MB distribution they couldn't squeeze in a 1K text file!) > >> MinGW is a C implementation that includes the gcc compiler and the >> Microsoft runtime library. > >clang can't get that far: "hello.c:1:10: fatal error: 'stdio.h' file not >found". I can't point it to where the stdio.h is, because it doesn't >exist. I used to think it was because such headers were built-in, but >when it's worked in the past, it might be because it searched my file >system for a gcc installation and quietly made use of gcc's files. > >But some good news at least: anything who's thinking of writing a C >compiler (there seem to be a few at the minute), apparently only has to >produce a bare compiler. Forget standard headers, libraries, linkers or >anything else. No need to actually make it do anything useful! You really have trouble imagining that the goals, problems and motivations of the writers of the compiler proper, the linker and the runtime libraries may not be different, and best addressed by different projects? Or that there are benefits from sharing those in various ways (gcc generates code for many non-Unix systems, and has few system dependencies, glib C works with many compilers and has large system dependencies, but having a common glibc or MSVCRT helps multi-language projects)? At the end of the day someone needs to package the bits together to get an actual implementation. Which does, of course, sometime lead to somewhat half-baked implementations like Mingw, where the library is not quite compatible with the compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-09-08 22:41 +0200 |
| Message-ID | <msnh37$k7n$1@dont-email.me> |
| In reply to | #69937 |
On 08/09/15 19:08, Keith Thompson wrote: > Bartc <bc@freeuk.com> writes: >> On 08/09/2015 16:13, Robert Wessel wrote: >>> On Tue, 8 Sep 2015 12:17:01 +0100, Bartc <bc@freeuk.com> wrote: >> >> [clang] >>>> (** It turns out that clang has been piggy-backing onto top of whatever >>>> gcc has been installed. It uses the include files and library files of >>>> gcc; possibly even its linker. By itself, it can't even compile Hello >>>> World, and that's a 400MB installation!) >>> >>> You do know that GCC doesn't have any of that stuff either >> >> Actually, no I didn't. > > Really? It's been mentioned here numerous times; how did you not know > that? I am fairly sure I remember threads the explained exactly this fact to Bart. Amongst other things, gcc is used with a wide range of libraries. On Linux, glibc is the norm - but it's not the only possibility. And in cross-compilations a fair number of different libraries are used. Some are general-purpose, some have lots of extra features, some are designed to be very small, some have a bias on speed (and predictability of speed), and some are very device-specific. It is not uncommon to package a gcc build together with a library and appropriate binutils (assembler, linker, librarian) - but that's a choice for the packager. The compiler itself is quite flexible. (And the same applies to llvm, although now that project also has its own linker and an assembler, I believe, rather than using the binutils ones.) > >> Although people are always on about the compiler >> and runtime library being distinct, they are generally supplied >> together. The person trying to program doesn't care: usually he or she >> just wants to go from C sources to executable or library. > > Yes, a compiler and a runtime library implementation are commonly > supplied together, because you need both of them (along with a linker, > etc.) to be able to compile and run C programs. > >> For example, on Windows (forget *nix which lives in a world of its own): >> >> lccwin contains a compiler, include files, linker and library files. >> >> So does Digital Mars C. >> >> So does Pelles C. >> >> So does Tiny C. > > Yes, *some* C implementations include both a compiler and a runtime > library implemented by the same group. Others do not. (I'll take your > word for it that the ones listed above do so; I'm not familiar with > them.) > >> And so does every install of gcc I've ever seen. In spades. >> >> (I installed something a few days ago, which might have been Mingw64, >> which contains 3500 ".a" library files, and 8200 .h files. Although I'm >> not sure exactly what I installed as I can't make head of tail of these >> install/package managers. But gcc on Windows does anyway comes with huge >> numbers of include files and libraries. > > MinGW is a C implementation that includes the gcc compiler and the > Microsoft runtime library. (I don't know whether the runtime library > is packaged along with it, or whether it depends on it already being on > the system.) Note also that there is the mingw-w64 project, which is a 32-bit and 64-bit gcc for Windows that includes a different library (not MS's stunted C library). I don't know off-hand if it is their own library or basically glibc (or something else), but I gather it is a reasonably complete C99 and C11 library (unlike MS's C library). > >> Actually, I'd quite like to know how to download a bare version of gcc!) > > Well, you could build it from source, but it's a little more > compilicated than the usual configure/make/make install sequence, > since gcc bootstraps itself during the build process. It's fairly easy these days (at least if you have a working msys environment). You don't need the separate bootstraping process - it is part of the standard "make" phase now. But you might want to spend a little more time looking at the configure options than for most programs - for example, you might want to choose which programming languages to support in your build. > >> (except >> > perhaps the linker, not sure where that comes from, but linkers are >> > historically system supplied, unlike compilers >> >> (I've just discovered I can use gcc's linker LD.EXE, a single 1.2MB >> executable, by itself. That solves a lot of problems, removes a 400MB >> dependency from one of my projects, and is a lot easier to use than via >> gcc where I usually haven't got a clue what it's up to.) > > On my Linux system, the linker (/usr/bin/ld) is provided by the > "binutils" package, which includes a number of other programs including > "ar", "as" (the assembler), "strip", et al. So there are (at least) > three different software packages (gcc, libc6, binutils) that together > make up the C implementation. And any of them could be replaced with > something else. Indeed. And while binutils is the most common source of as, ld, etc., on some other *nix systems, the native tools are preferred. > >> )? Hint: glibc is >>> maintained by an essentially entirely independent group of people >>> completely. Nor is glibc necessary for GCC - Mingw, for example, uses >>> gcc and the MS C library. >> >> I might forget glibc, if it makes life easier to just use the MSVCRT.DLL >> file guaranteed to be on every Windows machine. If using LD.EXE is >> viable, then it's usually to have control over exactly what is linked in. > MSVCRT.DLL can certainly be used as a C runtime library, if you don't mind its limitations and the slower speed compared to a better library with static linking.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-09-07 12:03 -0400 |
| Message-ID | <OziHx.6185$dc6.6042@fx23.iad> |
| In reply to | #69762 |
On 9/7/15 7:03 AM, Bartc wrote: > This might fail in unusual circumstances where an application is using > two C runtime libraries at the same time. But I'm not sure how likely > that is. > > (It has happened to me that one part of a program uses a statically > linked C library, while another calls functions in an dynamically loaded > library that is linked with another version of the C library.) > I'm pretty certain that this case is non-conforming behavior (or undefined behavior depending on who you are going to blame). Ultimately, the injection of 2 version of malloc into a program is a violation of the C standard (unless the implementation can totally hide this under the as-if rule).
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web