Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #63934 > unrolled thread
| Started by | bilsch <bilsch01@gmail.com> |
|---|---|
| First post | 2015-06-23 07:40 -0700 |
| Last post | 2015-07-21 12:47 +0200 |
| Articles | 20 on this page of 130 — 29 participants |
Back to article view | Back to comp.lang.c
OT - gcc for Windows not being recognized by Windows 7 bilsch <bilsch01@gmail.com> - 2015-06-23 07:40 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-23 15:48 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 bilsch <bilsch01@gmail.com> - 2015-06-23 08:15 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-23 17:46 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-23 17:00 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 01:55 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Keith Thompson <kst-u@mib.org> - 2015-06-23 15:18 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 00:43 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Tim Prince <tprince@computer.org> - 2015-06-23 18:54 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 09:56 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 09:34 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 09:58 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 11:21 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 11:27 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 13:41 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 13:14 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 14:24 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 13:37 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 16:32 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-24 13:33 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 16:34 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 13:25 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 19:03 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:28 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 19:52 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 19:57 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-24 21:36 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 22:06 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-25 08:05 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-25 10:11 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-25 03:25 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-25 12:49 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-25 13:21 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 James Kuyper <jameskuyper@verizon.net> - 2015-06-25 12:35 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 17:42 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 James Kuyper <jameskuyper@verizon.net> - 2015-06-25 13:09 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-25 18:31 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 James Kuyper <jameskuyper@verizon.net> - 2015-06-25 13:44 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-26 07:32 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-26 11:51 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 11:19 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 11:54 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 12:46 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-26 13:31 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-26 14:35 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 14:21 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 14:37 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 15:19 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Kleinecke <dkleinecke@gmail.com> - 2015-06-26 10:10 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 21:05 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-26 14:05 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 20:42 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-26 15:07 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 21:43 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-26 16:40 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-26 23:21 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-26 22:37 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-26 18:25 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Stephen Sprunk <stephen@sprunk.org> - 2015-06-26 15:14 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-26 15:30 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-26 14:38 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-06-25 21:27 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-26 11:54 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 jacobnavia <jacob@jacob.remcomp.fr> - 2015-06-26 07:30 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-25 17:48 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-06-25 14:59 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Kleinecke <dkleinecke@gmail.com> - 2015-06-25 08:10 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 01:45 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 06:35 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-05 06:47 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 15:34 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-07-05 11:20 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 17:50 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-05 10:29 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-07-05 12:49 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 19:19 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Martin Shobe <martin.shobe@yahoo.com> - 2015-07-05 14:22 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Geoff <geoff@invalid.invalid> - 2015-07-05 12:49 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-05 21:05 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-07-05 15:38 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 22:38 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 17:18 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Keith Thompson <kst-u@mib.org> - 2015-07-05 18:23 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-07-06 02:43 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-06 10:27 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-06 20:13 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 "Charles Richmond" <numerist@aquaporin4.com> - 2015-07-07 15:18 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-07 13:31 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-07 21:16 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 02:04 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 fir <profesor.fir@gmail.com> - 2015-07-05 01:33 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 13:35 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Heathfield <rjh@cpax.org.uk> - 2015-06-24 13:04 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 raltbos@xs4all.nl (Richard Bos) - 2015-07-03 17:36 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-03 19:22 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-03 23:37 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 00:58 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Ian Collins <ian-news@hotmail.com> - 2015-07-05 14:58 +1200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 11:41 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 11:50 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-05 12:18 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-07-20 16:40 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-05 12:20 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-07-20 16:43 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-20 16:03 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-07-21 12:42 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Robert Wessel <robertwessel2@yahoo.com> - 2015-07-21 14:36 -0500
Re: OT - gcc for Windows not being recognized by Windows 7 Geoff <geoff@invalid.invalid> - 2015-07-05 11:30 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Melzzzzz <mel@zzzzz.com> - 2015-07-05 21:08 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 20:26 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-05 15:45 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 Melzzzzz <mel@zzzzz.com> - 2015-07-05 21:57 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-05 21:28 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-05 23:39 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-05 23:39 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 Bartc <bc@freeuk.com> - 2015-07-06 12:56 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-06 12:58 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-06 09:55 -0400
Re: OT - gcc for Windows not being recognized by Windows 7 Richard Kettlewell <rjk@greenend.org.uk> - 2015-07-06 16:26 +0100
Re: OT - gcc for Windows not being recognized by Windows 7 Phil Carmody <pc+usenet@asdf.org> - 2015-07-08 19:55 +0300
Re: OT - gcc for Windows not being recognized by Windows 7 Ian Collins <ian-news@hotmail.com> - 2015-07-06 10:39 +1200
Re: OT - gcc for Windows not being recognized by Windows 7 luser droog <luser.droog@gmail.com> - 2015-07-05 20:30 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-07-20 16:28 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 raltbos@xs4all.nl (Richard Bos) - 2015-06-24 10:04 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 David Brown <david.brown@hesbynett.no> - 2015-06-24 13:42 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 Rosario19 <Ros@invalid.invalid> - 2015-06-24 09:22 +0200
Re: OT - gcc for Windows not being recognized by Windows 7 "Chris M. Thomasson" <nospam@nospam.nospam> - 2015-07-05 11:56 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 Geoff <geoff@invalid.invalid> - 2015-07-05 12:52 -0700
Re: OT - gcc for Windows not being recognized by Windows 7 gazelle@shell.xmission.com (Kenny McCormack) - 2015-07-05 20:40 +0000
Re: OT - gcc for Windows not being recognized by Windows 7 Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-07-21 12:47 +0200
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-24 16:34 +0200 |
| Message-ID | <mmef3o$hhf$2@dont-email.me> |
| In reply to | #64056 |
On 24/06/15 15:33, Kenny McCormack wrote: > In article <mme7g2$kdo$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> snarked: > ... >>> If you're delivering binary code you don't have the same problem. At >>> your end of it, you can do what you like. >> >> You might have heard the phrase "quality control" on occasion. It's not >> very common in the world of PC programming, but it's a different matter >> in embedded systems. > > I just don't think you guys are ever going to be each other's prom dates. > Perhaps I've been a bit rude in my wording - if so, sorry Bart.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 13:25 +0100 |
| Message-ID | <mme7hp$kfo$1@dont-email.me> |
| In reply to | #64045 |
On 24/06/15 13:14, Bartc wrote: > On 24/06/2015 12:41, David Brown wrote: >> On 24/06/15 12:21, Bartc wrote: > >>> I don't use makefiles. Example: http://pastebin.com/6wLQDPSd > >> Yes, but like most serious developers, I don't write 20,000 line >> single-file lumps of code and call it a "project". > > Why shouldn't it be called a 'project'? I guess it's for the same reason you don't call one customer a queue. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-24 19:03 +0100 |
| Message-ID | <mmerbj$56b$1@dont-email.me> |
| In reply to | #64049 |
On 24/06/2015 13:25, Richard Heathfield wrote: > On 24/06/15 13:14, Bartc wrote: >> On 24/06/2015 12:41, David Brown wrote: >>> On 24/06/15 12:21, Bartc wrote: >> >>>> I don't use makefiles. Example: http://pastebin.com/6wLQDPSd >> >>> Yes, but like most serious developers, I don't write 20,000 line >>> single-file lumps of code and call it a "project". >> >> Why shouldn't it be called a 'project'? > > I guess it's for the same reason you don't call one customer a queue. I still don't get it. So a dozen files totalling a few hundred lines counts as a project, but a 100,000-line program in one file doesn't? -- Bart
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 19:28 +0100 |
| Message-ID | <mmesqd$b4s$1@dont-email.me> |
| In reply to | #64087 |
On 24/06/15 19:03, Bartc wrote: > On 24/06/2015 13:25, Richard Heathfield wrote: >> On 24/06/15 13:14, Bartc wrote: >>> On 24/06/2015 12:41, David Brown wrote: >>>> On 24/06/15 12:21, Bartc wrote: >>> >>>>> I don't use makefiles. Example: http://pastebin.com/6wLQDPSd >>> >>>> Yes, but like most serious developers, I don't write 20,000 line >>>> single-file lumps of code and call it a "project". >>> >>> Why shouldn't it be called a 'project'? >> >> I guess it's for the same reason you don't call one customer a queue. > > I still don't get it. > > So a dozen files totalling a few hundred lines counts as a project, but > a 100,000-line program in one file doesn't? Do you see the word "project" as some kind of desirable award, like a Cub's badge for woodcraft? Generally, the way in which, historically, programmers have used the word "project" is to describe the collection of source files, header files, make file, data files, and so on that constitute the raw materials for building a program. It's a little like the word "regiment" - there is no universally-agreed definition of how many soldiers there are in a regiment, but we all know it's more than one. But hey, if it's important to you, by all means call your file a project. Why should anyone object? Vivre et laissez vivre. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-24 19:52 +0100 |
| Message-ID | <mmeu66$h59$1@dont-email.me> |
| In reply to | #64090 |
On 24/06/2015 19:28, Richard Heathfield wrote: > On 24/06/15 19:03, Bartc wrote: >> I still don't get it. >> >> So a dozen files totalling a few hundred lines counts as a project, but >> a 100,000-line program in one file doesn't? > > Do you see the word "project" as some kind of desirable award, like a > Cub's badge for woodcraft? Not particularly. I certainly don't see extra merit in making something huge, or in spreading it amongst as many files as possible. Actually it's much harder to keep things small. > Generally, the way in which, historically, programmers have used the > word "project" is to describe the collection of source files, header > files, make file, data files, and so on that constitute the raw > materials for building a program. It's a little like the word "regiment" > - there is no universally-agreed definition of how many soldiers there > are in a regiment, but we all know it's more than one. Source code isn't like soldiers. If you took all the source files and headers comprising a 'project', and refactored it into a single file (or simply concatenated them), is it any less of a project? I was just puzzled why the distinction was made. > But hey, if it's important to you, by all means call your file a > project. What's important is that someone can just download and compile with no hassle. That is easier to do as a single file, although there are practical limits. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 19:57 +0100 |
| Message-ID | <mmeuh9$ifs$1@dont-email.me> |
| In reply to | #64094 |
On 24/06/15 19:52, Bartc wrote: > On 24/06/2015 19:28, Richard Heathfield wrote: >> On 24/06/15 19:03, Bartc wrote: > >>> I still don't get it. >>> >>> So a dozen files totalling a few hundred lines counts as a project, but >>> a 100,000-line program in one file doesn't? >> >> Do you see the word "project" as some kind of desirable award, like a >> Cub's badge for woodcraft? > > Not particularly. I certainly don't see extra merit in making something > huge, or in spreading it amongst as many files as possible. Actually > it's much harder to keep things small. For some people, perhaps not so hard. For others... well, I saw your 20KLOC source file. It is true that there is no merit in using as many files as possible, but neither is there any merit in using as /few/ files as possible. There is, however, merit in organising the code in a useful way. For very, very, very tiny programs, this may mean putting all the source in one file. > If you took all the source files and > headers comprising a 'project', and refactored it into a single file (or > simply concatenated them), is it any less of a project? Yes. You have removed some of the organisational structure that made it easier to read, easier to understand, and therefore easier to maintain. <snip> -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-06-24 21:36 +0100 |
| Message-ID | <mmf4a9$a7p$1@dont-email.me> |
| In reply to | #64095 |
On 24/06/2015 19:57, Richard Heathfield wrote: > On 24/06/15 19:52, Bartc wrote: >> Not particularly. I certainly don't see extra merit in making something >> huge, or in spreading it amongst as many files as possible. Actually >> it's much harder to keep things small. > > For some people, perhaps not so hard. For others... well, I saw your > 20KLOC source file. Perhaps you missed the point that that file was for distribution only, not meant to be read. It's also generated code. The first 1000 lines are function prototypes that are needed in C but not in the original. Global names have also been mangled to avoid collisions in the single name-space of the file. (It's common also for binary executables to be distributed as single, monolithic blocks of data. But people don't like downloading executable code. This is the equivalent as text.) >> If you took all the source files and >> headers comprising a 'project', and refactored it into a single file (or >> simply concatenated them), is it any less of a project? > > Yes. You have removed some of the organisational structure that made it > easier to read, easier to understand, and therefore easier to maintain. At college I remember seeing a 2-3"-thick listing of a Pascal compiler, written in Pascal and as a single file, as the language didn't have modules. It looked clear enough from what I can remember. On the other hand, I've seen not particularly big C programs more recently that were exasperating to try and follow because the authors split them up into dozens of tiny modules and headers. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-24 22:06 +0100 |
| Message-ID | <mmf61q$gv8$1@dont-email.me> |
| In reply to | #64098 |
On 24/06/15 21:36, Bartc wrote: > On 24/06/2015 19:57, Richard Heathfield wrote: >> On 24/06/15 19:52, Bartc wrote: > >>> Not particularly. I certainly don't see extra merit in making something >>> huge, or in spreading it amongst as many files as possible. Actually >>> it's much harder to keep things small. >> >> For some people, perhaps not so hard. For others... well, I saw your >> 20KLOC source file. > > Perhaps you missed the point that that file was for distribution only, > not meant to be read. Okay, that's a fair point, and I have no wish to be unfair to you. In general terms, however, presumably you can appreciate that for distributions that /are/ intended to be read, a 20,000 line file would be over the top, and so we split things up into more manageable units, and those units - taken together - constitute "the project". <snip> > On the other hand, I've seen not particularly big C programs more > recently that were exasperating to try and follow because the authors > split them up into dozens of tiny modules and headers. As is so often the case in programming, there is a balance to be struck. Note, though, that tiny modules have historically been advantageous in the building of libraries, insofar as some linkers have worked on the principle of adding to an executable image all the *object files* it needs from a library - so putting each function in its own object file had a real and beneficial impact on the size of the executable image. (Is it still the case that linkers can only pull library code out at an object-file level? I don't know.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-25 08:05 +0200 |
| Message-ID | <mmg5k4$flj$1@dont-email.me> |
| In reply to | #64100 |
Le 24/06/2015 23:06, Richard Heathfield a écrit : > (Is it still the case that linkers can only pull library code out at an > object-file level? I don't know.) My linker doesn't. I just pull all the object file since it is very difficult to determine from the linker standpoint what is needed and what is not.. A global symbol could be referenced from some function pointer somewhere, then it could pull in other symbols etc. Obviously there are more sophisticated linkers. Microsoft can put each function in its own text section, allowing the linker to determine in a more fine grained fashion if a function or variable is needed or not. That slows down linking of large objects, and is a technology that requires more effort. I haven't put much effort into that right now, there are so many things to be done first. In general the linker is taken for granted. It shouldn't. It is a sophisticated thing, very difficumt to write, specially when the specs for the executable format are impossible or very difficult to find. And the absolute nightmare is a linker bug... You never see those but the programs crash for unknown reasons.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 10:11 +0200 |
| Message-ID | <mmgd0a$6kg$1@dont-email.me> |
| In reply to | #64107 |
On 25/06/15 08:05, jacobnavia wrote: > Le 24/06/2015 23:06, Richard Heathfield a écrit : >> (Is it still the case that linkers can only pull library code out at an >> object-file level? I don't know.) > > My linker doesn't. I just pull all the object file since it is very > difficult to determine from the linker standpoint what is needed and > what is not.. A global symbol could be referenced from some function > pointer somewhere, then it could pull in other symbols etc. > > Obviously there are more sophisticated linkers. Microsoft can put each > function in its own text section, allowing the linker to determine in a > more fine grained fashion if a function or variable is needed or not. > Many compilers/linkers do that. With gcc, you can arrange for each generated function to go in a little section by itself, and the linker only uses the sections it needs. It is certainly more complicated than a naive linker, but I don't think it causes much slowdown - at least, not compared to the rest of the compilation and linking process. Some compilers are even more sophisticated, and do some kind of link-time optimisation or whole-program optimisation. (clang is famous for it, gcc has LTO which has progressed nicely over the last few versions, and many embedded compilers have it. I have no idea about MSVC.) Here the compiler stores internal code trees in the object file or libraries, in addition to or instead of traditional lumps of assembled code. Then during the linking process, these are merged into one huge code tree - allowing cross-module and cross-library optimisations such as constant propagation, dead-code elimination, inlining, etc. Of course, this is a complicated business, and can be very time-consuming, and it can make debugging a nightmare. > That slows down linking of large objects, and is a technology that > requires more effort. I haven't put much effort into that right now, > there are so many things to be done first. > > In general the linker is taken for granted. It shouldn't. It is a > sophisticated thing, very difficumt to write, specially when the specs > for the executable format are impossible or very difficult to find. > > And the absolute nightmare is a linker bug... You never see those but > the programs crash for unknown reasons. You could consider doing things the way gcc does - the gcc folks write the compiler, but use an external linker (usually the one from binutils), assembler and librarian. That way they don't have to deal with the executable formats or linking.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-06-25 03:25 -0500 |
| Message-ID | <k6enoad8qhb2h0fm2sfl8vlmfi9s17st2a@4ax.com> |
| In reply to | #64110 |
On Thu, 25 Jun 2015 10:11:07 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 25/06/15 08:05, jacobnavia wrote: >> Le 24/06/2015 23:06, Richard Heathfield a écrit : >>> (Is it still the case that linkers can only pull library code out at an >>> object-file level? I don't know.) >> >> My linker doesn't. I just pull all the object file since it is very >> difficult to determine from the linker standpoint what is needed and >> what is not.. A global symbol could be referenced from some function >> pointer somewhere, then it could pull in other symbols etc. >> >> Obviously there are more sophisticated linkers. Microsoft can put each >> function in its own text section, allowing the linker to determine in a >> more fine grained fashion if a function or variable is needed or not. >> > >Many compilers/linkers do that. With gcc, you can arrange for each >generated function to go in a little section by itself, and the linker >only uses the sections it needs. It is certainly more complicated than >a naive linker, but I don't think it causes much slowdown - at least, >not compared to the rest of the compilation and linking process. The linker on zOS has (since the S/360 days), actually been able to remove and replace a text segment (aka a "CSECT") from a linked module. The overlay capabilities (now mostly gone, replaced by virtual memory) in the S/360 days would impress almost anyone today. >Some compilers are even more sophisticated, and do some kind of >link-time optimisation or whole-program optimisation. (clang is famous >for it, gcc has LTO which has progressed nicely over the last few >versions, and many embedded compilers have it. I have no idea about >MSVC.) MSVC has supported LTCG since about VS2003. GCC is very much the late-comer with LTCG. > Here the compiler stores internal code trees in the object file >or libraries, in addition to or instead of traditional lumps of >assembled code. Then during the linking process, these are merged into >one huge code tree - allowing cross-module and cross-library >optimisations such as constant propagation, dead-code elimination, >inlining, etc. Of course, this is a complicated business, and can be >very time-consuming, and it can make debugging a nightmare. That doesn't actually put much of a burden on the linker. Everyone has done approximately the same thing. The "obj" file containing the code tree contains an indication of the compiler back end that should process it. In the case of MSVC it's actually a path to the DLL that is the back end of the compiler. The linker just gathers up all the object modules going to a particular back end, hands them off to that back end, and that back end generates a normal object (one containing actual machine code instead of a parse tree). The linker then processes those object files as usual. The major burden is that the compiler back end now has to be able to merge several parse trees. For most cases in C and C++, that's simpler than it sounds and really only requires fixing up some names to manage their visibility (for example, consider if two translation units defined "static int x;").
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-25 12:49 +0200 |
| Message-ID | <mmgm9d$5db$1@dont-email.me> |
| In reply to | #64111 |
On 25/06/15 10:25, Robert Wessel wrote: > On Thu, 25 Jun 2015 10:11:07 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> On 25/06/15 08:05, jacobnavia wrote: >>> Le 24/06/2015 23:06, Richard Heathfield a écrit : >>>> (Is it still the case that linkers can only pull library code out at an >>>> object-file level? I don't know.) >>> >>> My linker doesn't. I just pull all the object file since it is very >>> difficult to determine from the linker standpoint what is needed and >>> what is not.. A global symbol could be referenced from some function >>> pointer somewhere, then it could pull in other symbols etc. >>> >>> Obviously there are more sophisticated linkers. Microsoft can put each >>> function in its own text section, allowing the linker to determine in a >>> more fine grained fashion if a function or variable is needed or not. >>> >> >> Many compilers/linkers do that. With gcc, you can arrange for each >> generated function to go in a little section by itself, and the linker >> only uses the sections it needs. It is certainly more complicated than >> a naive linker, but I don't think it causes much slowdown - at least, >> not compared to the rest of the compilation and linking process. > > > The linker on zOS has (since the S/360 days), actually been able to > remove and replace a text segment (aka a "CSECT") from a linked > module. The overlay capabilities (now mostly gone, replaced by > virtual memory) in the S/360 days would impress almost anyone today. > > >> Some compilers are even more sophisticated, and do some kind of >> link-time optimisation or whole-program optimisation. (clang is famous >> for it, gcc has LTO which has progressed nicely over the last few >> versions, and many embedded compilers have it. I have no idea about >> MSVC.) > > > MSVC has supported LTCG since about VS2003. GCC is very much the > late-comer with LTCG. gcc felt the pressure from clang/llvm rather than MSVC, but there is no doubt that it was somewhat late to the LTCG party. The rise of clang/llvm has been good for gcc - their "sibling rivalry" has lead to progress on both sides, as well as a lot of cooperation. > > >> Here the compiler stores internal code trees in the object file >> or libraries, in addition to or instead of traditional lumps of >> assembled code. Then during the linking process, these are merged into >> one huge code tree - allowing cross-module and cross-library >> optimisations such as constant propagation, dead-code elimination, >> inlining, etc. Of course, this is a complicated business, and can be >> very time-consuming, and it can make debugging a nightmare. > > > That doesn't actually put much of a burden on the linker. Everyone > has done approximately the same thing. The "obj" file containing the > code tree contains an indication of the compiler back end that should > process it. In the case of MSVC it's actually a path to the DLL that > is the back end of the compiler. The linker just gathers up all the > object modules going to a particular back end, hands them off to that > back end, and that back end generates a normal object (one containing > actual machine code instead of a parse tree). The linker then > processes those object files as usual. > The real challenge is not so much the compilation or linking (as you say, it's mostly just a matter of passing around code trees that the compiler already knows how to handle). It's making it scalable that's hard. With normal compilation and linking, you usually only have to re-compile modules that change, and that re-compilation can be done in parallel. The linking is relatively quick, though typically done serially. With LTO done naively you have to do a large amount of the project's real compilation at link time with optimisation and compilation of a single massive combined code tree - all as one thread. Again, I can't answer for other compilers (I'm guessing they are similar), but gcc has moved through several generations with its LTO in order to make it scale efficiently so that you can use it for large projects compiled on multi-core machines. > The major burden is that the compiler back end now has to be able to > merge several parse trees. For most cases in C and C++, that's > simpler than it sounds and really only requires fixing up some names > to manage their visibility (for example, consider if two translation > units defined "static int x;"). > gcc had this for quite a while, with a "whole-program" flag. It was limited to C (no C++ or other languages), and you had to pass all the source files to the gcc driver at once for compilation and linking. But it worked roughly like taking all static data and functions and adding the filename to their names, and then taking all non-static data and functions (except "main") and making them static, then compiling everything as one great lump. LTO has a similar effect in many ways (and replaces the whole-program flag in gcc).
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-06-25 13:21 +0000 |
| Message-ID | <mmgv9g$ra2$1@speranza.aioe.org> |
| In reply to | #64111 |
Robert Wessel <robertwessel2@yahoo.com> wrote: > On Thu, 25 Jun 2015 10:11:07 +0200, David Brown > <david.brown@hesbynett.no> wrote: (snip) >>Many compilers/linkers do that. With gcc, you can arrange for each >>generated function to go in a little section by itself, and the linker >>only uses the sections it needs. It is certainly more complicated than >>a naive linker, but I don't think it causes much slowdown - at least, >>not compared to the rest of the compilation and linking process. > The linker on zOS has (since the S/360 days), actually been able to > remove and replace a text segment (aka a "CSECT") from a linked > module. The overlay capabilities (now mostly gone, replaced by > virtual memory) in the S/360 days would impress almost anyone today. More specifically, the OS/360 linker knows how to read its own output, in addition to object modules. That, and the rule that if a CSECT is seen more than once, the first one is used, allows for editing. Supply an object module with a new function, load in the previously linked program, and write out the result. Also, you can remove the overlay structure from a previously linked program by reading it in to the linker, then writing it out without any overlay statements. And libraries, such as the C library, on disk are written by the linker, as it is more efficient than the object module format. (snip) -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-25 12:35 -0400 |
| Message-ID | <558C2DB4.9080806@verizon.net> |
| In reply to | #64107 |
On 06/25/2015 02:05 AM, jacobnavia wrote: > Le 24/06/2015 23:06, Richard Heathfield a écrit : >> (Is it still the case that linkers can only pull library code out at an >> object-file level? I don't know.) > > My linker doesn't. I just pull all the object file since it is very > difficult to determine from the linker standpoint what is needed and > what is not.. A global symbol could be referenced from some function > pointer somewhere, then it could pull in other symbols etc. That comment confuses me, being inconsistent with my understanding (limited as it is) of how linkage works. If I write code like the following: void (*f)(void) = external_function; I expect the object file to contain a record indicating that external_function is a external reference that must be resolved. I expect the linker to find that record, and search for an object module in the provided libraries that contains a record indicating that it provides an eternal definition for that function, and to load that module (and only that module) from whichever library it's in. I expect that object module to itself contain records listing any other external symbols that external_function() itself connects to, and for the linker to recursively track down those references too. What am I misunderstanding about this process that makes it so difficult that you prefer to pull all of the object files from a library? For the typical program that I write, which uses only a few modules (directly or indirectly) from each of several huge libraries, I'd expect your linker's approach to make the resulting program dozens of times bigger than it needed to be.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 17:42 +0100 |
| Message-ID | <mmhaub$j2g$1@dont-email.me> |
| In reply to | #64133 |
On 25/06/15 17:35, James Kuyper wrote: > On 06/25/2015 02:05 AM, jacobnavia wrote: >> Le 24/06/2015 23:06, Richard Heathfield a écrit : >>> (Is it still the case that linkers can only pull library code out at an >>> object-file level? I don't know.) >> >> My linker doesn't. I just pull all the object file since it is very >> difficult to determine from the linker standpoint what is needed and >> what is not.. A global symbol could be referenced from some function >> pointer somewhere, then it could pull in other symbols etc. > > That comment confuses me, being inconsistent with my understanding > (limited as it is) of how linkage works. If I write code like the following: > <snip - see parent article for full text if you need it> > > What am I misunderstanding about this process that makes it so difficult > that you prefer to pull all of the object files from a library? I don't *think* that's what he said. I *think* he said "pull all the object file" as opposed to "pull from the object file only those functions and objects that are required for the program". > For the > typical program that I write, which uses only a few modules (directly or > indirectly) from each of several huge libraries, I'd expect your > linker's approach to make the resulting program dozens of times bigger > than it needed to be. If he means what I think he means, it is consistent with my understanding of how linkers used to work (and may still work), and is a perfectly reasonable approach (although it /may/ be out-dated, if linker techniques have moved on rapidly while I wasn't watching). -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-25 13:09 -0400 |
| Message-ID | <558C35C9.5090603@verizon.net> |
| In reply to | #64135 |
On 06/25/2015 12:42 PM, Richard Heathfield wrote: > On 25/06/15 17:35, James Kuyper wrote: >> On 06/25/2015 02:05 AM, jacobnavia wrote: >>> Le 24/06/2015 23:06, Richard Heathfield a écrit : >>>> (Is it still the case that linkers can only pull library code out at an >>>> object-file level? I don't know.) >>> >>> My linker doesn't. I just pull all the object file since it is very >>> difficult to determine from the linker standpoint what is needed and >>> what is not.. A global symbol could be referenced from some function >>> pointer somewhere, then it could pull in other symbols etc. >> >> That comment confuses me, being inconsistent with my understanding >> (limited as it is) of how linkage works. If I write code like the following: >> > <snip - see parent article for full text if you need it> >> >> What am I misunderstanding about this process that makes it so difficult >> that you prefer to pull all of the object files from a library? > > I don't *think* that's what he said. I *think* he said "pull all the > object file" as opposed to "pull from the object file only those > functions and objects that are required for the program". I assumed that "pull all of the object file" was a typo for "pull all of the object files". You're suggesting that he meant "pull the entire object file"? If so, that's entirely reasonable, and I never would have expected the linker to do anything other than that. I apologize for the misunderstanding.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-06-25 18:31 +0100 |
| Message-ID | <mmhdr0$v03$1@dont-email.me> |
| In reply to | #64140 |
On 25/06/15 18:09, James Kuyper wrote: <snip> > I assumed that "pull all of the object file" was a typo for "pull all of > the object files". You're suggesting that he meant "pull the entire > object file"? Yes. FWIW I jumped to the same conclusion, and then I stopped to think about it for a moment, because that /couldn't/ be what he meant. Jacob and I have had our differences in the past, and no doubt many differences remain, but he's not stupid and I just don't think he would write a linker that way. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-06-25 13:44 -0400 |
| Message-ID | <558C3E1B.4070601@verizon.net> |
| In reply to | #64145 |
On 06/25/2015 01:31 PM, Richard Heathfield wrote: > On 25/06/15 18:09, James Kuyper wrote: > > <snip> > >> I assumed that "pull all of the object file" was a typo for "pull all of >> the object files". You're suggesting that he meant "pull the entire >> object file"? > > Yes. FWIW I jumped to the same conclusion, and then I stopped to think > about it for a moment, because that /couldn't/ be what he meant. > > Jacob and I have had our differences in the past, and no doubt many > differences remain, but he's not stupid and I just don't think he would > write a linker that way. I could say much the same thing, except that I was less certain than you are that it would have have been a completely unreasonable way to design a linker. I'm only a user of linkers, I've no detailed understand of their design. I was actually expecting a response that would explain why it was reasonable, at least under some circumstances - and I then expected to argue with him about those circumstances.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2015-06-26 07:32 +0200 |
| Message-ID | <mmio22$3eh$2@dont-email.me> |
| In reply to | #64151 |
Le 25/06/2015 19:44, James Kuyper a écrit : > On 06/25/2015 01:31 PM, Richard Heathfield wrote: >> On 25/06/15 18:09, James Kuyper wrote: >> >> <snip> >> >>> I assumed that "pull all of the object file" was a typo for "pull all of >>> the object files". You're suggesting that he meant "pull the entire >>> object file"? >> >> Yes. FWIW I jumped to the same conclusion, and then I stopped to think >> about it for a moment, because that /couldn't/ be what he meant. >> >> Jacob and I have had our differences in the past, and no doubt many >> differences remain, but he's not stupid and I just don't think he would >> write a linker that way. > > I could say much the same thing, except that I was less certain than you > are that it would have have been a completely unreasonable way to design > a linker. I'm only a user of linkers, I've no detailed understand of > their design. I was actually expecting a response that would explain why > it was reasonable, at least under some circumstances - and I then > expected to argue with him about those circumstances. > Sorry for the delay, I was very busy yesterday at a customer site... My linker does NOT pull ALL the object files from a library, just the ones that are referenced elsewhere. But WITHIN an object file I do not try to figure out if all of it is needed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-06-26 11:51 +0200 |
| Message-ID | <mmj77o$hsa$1@dont-email.me> |
| In reply to | #64195 |
On 26/06/15 07:32, jacobnavia wrote: > Le 25/06/2015 19:44, James Kuyper a écrit : >> On 06/25/2015 01:31 PM, Richard Heathfield wrote: >>> On 25/06/15 18:09, James Kuyper wrote: >>> >>> <snip> >>> >>>> I assumed that "pull all of the object file" was a typo for "pull >>>> all of >>>> the object files". You're suggesting that he meant "pull the entire >>>> object file"? >>> >>> Yes. FWIW I jumped to the same conclusion, and then I stopped to think >>> about it for a moment, because that /couldn't/ be what he meant. >>> >>> Jacob and I have had our differences in the past, and no doubt many >>> differences remain, but he's not stupid and I just don't think he would >>> write a linker that way. >> >> I could say much the same thing, except that I was less certain than you >> are that it would have have been a completely unreasonable way to design >> a linker. I'm only a user of linkers, I've no detailed understand of >> their design. I was actually expecting a response that would explain why >> it was reasonable, at least under some circumstances - and I then >> expected to argue with him about those circumstances. >> > > Sorry for the delay, I was very busy yesterday at a customer site... > > My linker does NOT pull ALL the object files from a library, just the > ones that are referenced elsewhere. But WITHIN an object file I do not > try to figure out if all of it is needed. > That's what I (and Richard) thought you meant. It is a common technique, which is fast and simple. gcc/binutils uses it too, unless you use link-time optimisation or you specify compiling with "-ffunctionsections" to put every function in its own sections, and linking with "--gc-sections" to tell the linker to omit sections that are never accessed. This is the reason why low-level libraries often have one function per file - then each function has its own object file, and these files are collected together in a library archive. The linker then takes only the object files it needs from the library, but it always takes the whole object file no matter how much of the file it actually needs. Since libraries typically contain a great many functions that will not be needed in any given program, while user-level code typically contains little dead or unused code, this works out fairly well in practice.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web