Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #91437 > unrolled thread
| Started by | luser droog <luser.droog@gmail.com> |
|---|---|
| First post | 2016-07-31 15:31 -0700 |
| Last post | 2016-08-08 22:12 -0700 |
| Articles | 20 on this page of 144 — 28 participants |
Back to article view | Back to comp.lang.c
Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-07-31 15:31 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-07-31 15:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:21 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 20:34 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 12:14 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 12:46 -0700
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 15:56 -0400
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 14:28 -0700
Re: Extending C with GC? Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-01 23:37 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 15:03 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-02 00:11 +0200
Re: Extending C with GC? "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-01 18:19 -0400
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-02 12:46 -0500
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-03 15:26 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 15:49 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:07 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-03 19:26 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-04 14:55 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-03 20:38 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 05:10 -0700
Re: Extending C with GC? Siri Cruise <chine.bleu@yahoo.com> - 2016-08-04 05:57 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 06:13 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 07:24 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-04 12:47 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 23:32 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 10:09 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-05 20:32 +1200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-05 06:14 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:14 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-06 13:23 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 04:38 -0700
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 04:34 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 05:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:05 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 06:12 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:02 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 06:11 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:50 +0100
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-06 07:57 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 17:02 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:20 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 14:27 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-06 14:45 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 09:59 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-06 19:38 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 17:03 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 09:54 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-07 21:53 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 11:34 +0100
Re: Extending C with GC? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-08-07 12:06 +0000
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-07 14:10 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 15:38 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:32 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 23:44 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 16:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 01:42 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:56 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:20 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-08 09:39 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 02:30 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:15 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 01:24 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 02:08 +0100
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 18:49 -0700
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-08 03:28 +0100
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 12:14 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 07:37 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 20:56 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 08:11 +1200
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-07 22:19 +0200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:23 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 14:29 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-07 22:36 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 15:04 -0700
Re: Extending C with GC? jameskuyper@verizon.net - 2016-08-07 15:19 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 00:04 +0100
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 16:20 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:21 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:35 +0100
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:13 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 11:53 -0700
Re: Extending C with GC? raltbos@xs4all.nl (Richard Bos) - 2016-08-10 12:58 +0000
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-10 07:05 -0700
Re: Extending C with GC? Ken Brody <kenbrody@spamcop.net> - 2016-08-10 12:29 -0400
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 21:15 +0100
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-08 08:57 -0700
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-07 15:37 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 14:58 -0700
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 15:26 +1200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 10:26 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:13 +1200
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-08 10:41 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-08 12:00 +0200
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 22:07 +1200
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-08 12:57 +0200
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-08 18:12 +0100
Re: Extending C with GC? Ian Collins <ian-news@hotmail.com> - 2016-08-08 21:25 +1200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-08 02:57 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-07 13:28 -0700
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-07 05:42 -0700
Re: Extending C with GC? Florian Weimer <fw@deneb.enyo.de> - 2016-08-07 11:49 +0200
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:18 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-06 19:27 +0200
Re: Extending C with GC? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-08-06 10:55 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-06 12:31 -0700
Re: Extending C with GC? James Kuyper <jameskuyper@verizon.net> - 2016-08-03 22:36 -0400
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 10:57 +0200
Re: Extending C with GC? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-04 04:09 -0700
Re: Extending C with GC? David Brown <david.brown@hesbynett.no> - 2016-08-04 14:01 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 07:52 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-04 08:57 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 09:19 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 12:30 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-04 15:21 -0700
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-04 16:50 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-05 07:31 -0700
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 16:01 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-04 21:00 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-04 20:26 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 10:37 +0200
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:52 +0100
Re: Extending C with GC? antispam@math.uni.wroc.pl - 2016-08-21 00:09 +0000
Re: Extending C with GC? Gareth Owen <gwowen@gmail.com> - 2016-08-21 08:58 +0100
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-21 10:48 +0200
Re: Extending C with GC? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-08-21 19:58 +0200
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-22 08:46 -0700
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-26 02:24 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-26 13:37 -0700
Re: Extending C with GC? Melzzzzz <mel@zzzzz.com> - 2016-08-27 00:41 +0200
Re: Extending C with GC? Öö Tiib <ootiib@hot.ee> - 2016-08-28 06:12 -0700
Re: Extending C with GC? BartC <bc@freeuk.com> - 2016-08-05 10:06 +0100
Re: Extending C with GC? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-05 15:26 +0100
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 08:11 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-05 17:43 +0200
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-05 15:28 -0700
Re: Extending C with GC? BGB <cr88192@hotmail.com> - 2016-08-04 17:11 -0500
Re: Extending C with GC? Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-31 17:35 -0700
Re: Extending C with GC? jacobnavia <jacob@jacob.remcomp.fr> - 2016-08-01 07:45 +0200
Re: Extending C with GC? Keith Thompson <kst-u@mib.org> - 2016-08-01 08:49 -0700
Re: Extending C with GC? supercat@casperkitty.com - 2016-08-01 09:06 -0700
Re: Extending C with GC? Aleksandar Kuktin <akuktin@gmail.com> - 2016-08-05 18:11 +0000
Re: Extending C with GC? luser droog <luser.droog@gmail.com> - 2016-08-05 11:24 -0700
Re: Extending C with GC? "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-08-08 22:12 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-08-06 19:20 +0200 |
| Message-ID | <no569h$6as$2@dont-email.me> |
| In reply to | #91809 |
Le 06/08/2016 à 15:11, Malcolm McLean a écrit : > No I'm not. > I've no connection with Jacob Navia other than that we both contribute > to comp.lang.c. Confirmed > But my understanding is that lcc-win comes with a garbage collector > which can be disabled, in which case the compiler is a standard > C compiler with essentially no GC overhead, Yes or used, in which case > Jacob takes advantage of the fact that he controls both the compiler > and the garbage collector to use some sort of pointer tagging system > that enables GC to work more efficiently than with a compiler > independent system. > I don't know however. I haven't examined the source. > No, I am PLANNING to do that eventually, substituting the GC with a compiler conyrolled GC. See the discussion "A GC proposal" in this discussion group
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-06 14:27 +0100 |
| Message-ID | <no4ok3$q8v$1@dont-email.me> |
| In reply to | #91807 |
On 06/08/2016 14:02, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >>> >>> Ian Collins, do you have an answer? If there is a C compiler with >>> integrated GC, I'd like to have a look at its design. >>> >> Jacob's lcc-win. >> However it's closed source. The GC is one of the major competitive >> advantages, and you can't reasonably expect Jacob to give away his >> business's assets to satisfy your curiosity. > > Are you sure? To quote from an admittedly rather old copy of the > lcc-win's manual: > > "Lcc-win comes with an automatic memory manager (also called garbage > collector in the literature) written by Hans Boehm." > > Now it's quite possible a lot of work was needed to make the GC library > work with lcc-win, so maybe there is a significant business assets here, > but Rick could surely get 99% of the design just be reading the GC > sources. Sure. If I wanted to try it out right now, I can just write: #include <gc.h> .... GC_MALLOC(N); if I use lccwin. With any other compiler, this won't work. The instructions in your link are mainly designed for Linux users (with "./configure" lines everywhere). (lccwin also includes the file gc.dll. I don't know if this will just work with any C compiler. It's a bit cheeky however to download lccwin just to swipe its ready-built GC library to use elsewhere!) (I have a mild interest in trying out such a GC in a test version of one of my interpreters, which currently uses reference counting. I suspect the difference will be small, but it would be useful to find out. But it doesn't do away with all problems: if I wanted to duplicate a data structure with circular references for example, I don't think a GC would help.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-06 14:45 +0100 |
| Message-ID | <87eg62nh9b.fsf@bsb.me.uk> |
| In reply to | #91811 |
BartC <bc@freeuk.com> writes: > On 06/08/2016 14:02, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: >>>> >>>> Ian Collins, do you have an answer? If there is a C compiler with >>>> integrated GC, I'd like to have a look at its design. >>>> >>> Jacob's lcc-win. >>> However it's closed source. The GC is one of the major competitive >>> advantages, and you can't reasonably expect Jacob to give away his >>> business's assets to satisfy your curiosity. >> >> Are you sure? To quote from an admittedly rather old copy of the >> lcc-win's manual: >> >> "Lcc-win comes with an automatic memory manager (also called garbage >> collector in the literature) written by Hans Boehm." >> >> Now it's quite possible a lot of work was needed to make the GC library >> work with lcc-win, so maybe there is a significant business assets here, >> but Rick could surely get 99% of the design just be reading the GC >> sources. > > Sure. If I wanted to try it out right now, I can just write: > > #include <gc.h> > .... > GC_MALLOC(N); > > if I use lccwin. With any other compiler, this won't work. The > instructions in your link are mainly designed for Linux users (with > "./configure" lines everywhere). The link was for Rick to start learning how the library works -- looking at the source and reading the references. I don't know the best place to get a pre-built Windows version. On my system I just install the package. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 09:59 -0700 |
| Message-ID | <68fcbc3e-2320-463d-8cfc-bff6f4d04138@googlegroups.com> |
| In reply to | #91811 |
On Saturday, August 6, 2016 at 9:27:43 AM UTC-4, Bart wrote: > On 06/08/2016 14:02, Ben Bacarisse wrote: > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > >> On Saturday, August 6, 2016 at 12:14:22 PM UTC+1, Rick C. Hodgin wrote: > >>> > >>> Ian Collins, do you have an answer? If there is a C compiler with > >>> integrated GC, I'd like to have a look at its design. > >>> > >> Jacob's lcc-win. > >> However it's closed source. The GC is one of the major competitive > >> advantages, and you can't reasonably expect Jacob to give away his > >> business's assets to satisfy your curiosity. > > > > Are you sure? To quote from an admittedly rather old copy of the > > lcc-win's manual: > > > > "Lcc-win comes with an automatic memory manager (also called garbage > > collector in the literature) written by Hans Boehm." > > > > Now it's quite possible a lot of work was needed to make the GC library > > work with lcc-win, so maybe there is a significant business assets here, > > but Rick could surely get 99% of the design just be reading the GC > > sources. > > Sure. If I wanted to try it out right now, I can just write: > > #include <gc.h> > .... > GC_MALLOC(N); > > if I use lccwin. With any other compiler, this won't work. The > instructions in your link are mainly designed for Linux users (with > "./configure" lines everywhere). > > (lccwin also includes the file gc.dll. I don't know if this will just > work with any C compiler. It's a bit cheeky however to download lccwin > just to swipe its ready-built GC library to use elsewhere!) You can gain a lot of software use by learning a few cross-platform tools. Install CYGWIN, for example, and install the necessary libraries through MSYS, and then run ./configure from inside the bash terminal (like a command window) and it will build it for you just as if you were in a Linux environment, except that it will generate Windows-compatible files. > (I have a mild interest in trying out such a GC in a test version of one > of my interpreters, which currently uses reference counting. I suspect > the difference will be small, but it would be useful to find out. > > But it doesn't do away with all problems: if I wanted to duplicate a > data structure with circular references for example, I don't think a GC > would help.) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-06 19:38 +0100 |
| Message-ID | <no5ar4$n1d$1@dont-email.me> |
| In reply to | #91821 |
On 06/08/2016 17:59, Rick C. Hodgin wrote: > On Saturday, August 6, 2016 at 9:27:43 AM UTC-4, Bart wrote: >> if I use lccwin. With any other compiler, this won't work. The >> instructions in your link are mainly designed for Linux users (with >> "./configure" lines everywhere). > You can gain a lot of software use by learning a few cross-platform tools. > Install CYGWIN, for example, and install the necessary libraries through > MSYS, and then run ./configure from inside the bash terminal (like a command > window) and it will build it for you just as if you were in a Linux > environment, except that it will generate Windows-compatible files. No. A million times No. That is just giving in to the monster. I don't want to distribute a modest *portable* *C* program but expect people who want to compile to go to all this trouble of downloading practically an entire OS to do so. Expecting them to run 30,000-line configuration file for reasons that *no-one* fully understands (because that's how it's always been done) is completely WRONG. The more people making a stand against this the better. A C program should need nothing more than a C compiler to build it. If it is necessary to run scripts to create part of the project, then devise some simpler, more portable scheme to do that (like having another C program; no extra tools needed). Or just admit that the program is NOT 100% C. > You can gain a lot of software use by learning a few cross-platform tools. And they are hardly cross-platform when they insist on bringing their own platform with them! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-08-06 17:03 -0700 |
| Message-ID | <36309d12-d08e-4817-b2e5-7d9b974f0fc0@googlegroups.com> |
| In reply to | #91826 |
On Saturday, August 6, 2016 at 2:38:36 PM UTC-4, Bart wrote: > On 06/08/2016 17:59, Rick C. Hodgin wrote: > > On Saturday, August 6, 2016 at 9:27:43 AM UTC-4, Bart wrote: > > >> if I use lccwin. With any other compiler, this won't work. The > >> instructions in your link are mainly designed for Linux users (with > >> "./configure" lines everywhere). > > > You can gain a lot of software use by learning a few cross-platform tools. > > Install CYGWIN, for example, and install the necessary libraries through > > MSYS, and then run ./configure from inside the bash terminal (like a command > > window) and it will build it for you just as if you were in a Linux > > environment, except that it will generate Windows-compatible files. > > No. A million times No. That is just giving in to the monster. > > I don't want to distribute a modest *portable* *C* program but expect > people who want to compile to go to all this trouble of downloading > practically an entire OS to do so. > > Expecting them to run 30,000-line configuration file for reasons that > *no-one* fully understands (because that's how it's always been done) is > completely WRONG. Nobody else would have to do that, Bart. You would download and install the source files, and then include a DLL or OBJ files which are included in your distributed project. You could include a readme.txt file on how you built it so those who want to build it can. You can also refactor the source code so it is a single source file, and distribute it that way. You are not locked into that system you receive the source code in, but it is how you will receive it. The only other alternative is to start building your own GNU-like project, and I can tell you from personal experience ... it's a lot of work. > The more people making a stand against this the better. > > A C program should need nothing more than a C compiler to build it. If > it is necessary to run scripts to create part of the project, then > devise some simpler, more portable scheme to do that (like having > another C program; no extra tools needed). Or just admit that the > program is NOT 100% C. > > > You can gain a lot of software use by learning a few cross-platform > tools. > > And they are hardly cross-platform when they insist on bringing their > own platform with them! It's only to build the DLL or .OBJ files, Bart. You can, from that day forward, statically link to them. You do not need to re-build from source again, or have anybody else ever rebuild from source. It's just the mechanism to get you from the source code to the final product, but once the final product is built ... it's built. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 09:54 +0100 |
| Message-ID | <no6svl$v2h$1@dont-email.me> |
| In reply to | #91832 |
On 07/08/2016 01:03, Rick C. Hodgin wrote: > On Saturday, August 6, 2016 at 2:38:36 PM UTC-4, Bart wrote: >> On 06/08/2016 17:59, Rick C. Hodgin wrote: >>> On Saturday, August 6, 2016 at 9:27:43 AM UTC-4, Bart wrote: >> >>>> if I use lccwin. With any other compiler, this won't work. The >>>> instructions in your link are mainly designed for Linux users (with >>>> "./configure" lines everywhere). >> >>> You can gain a lot of software use by learning a few cross-platform tools. >>> Install CYGWIN, for example, and install the necessary libraries through >>> MSYS, and then run ./configure from inside the bash terminal (like a command >>> window) and it will build it for you just as if you were in a Linux >>> environment, except that it will generate Windows-compatible files. >> >> No. A million times No. That is just giving in to the monster. >> >> I don't want to distribute a modest *portable* *C* program but expect >> people who want to compile to go to all this trouble of downloading >> practically an entire OS to do so. >> >> Expecting them to run 30,000-line configuration file for reasons that >> *no-one* fully understands (because that's how it's always been done) is >> completely WRONG. > > Nobody else would have to do that, Bart. You would download and install > the source files, and then include a DLL or OBJ files which are included > in your distributed project. You could include a readme.txt file on how > you built it so those who want to build it can. > > You can also refactor the source code so it is a single source file, and > distribute it that way. You've got it back to front. Probably everyone else is happy to jump through all those hoops (perhaps because they've always had to do it and think that's how it must be). I'm not! Anyway why should I have to do someone else's work for them? There might also be technical reasons why binary distributions are unacceptable. But I tell you what: if you (or anyone else) can tell me exactly what that configure script does (and it's only 20K lines in this case not 30K), then I'll think about it. Maybe. Otherwise, as I see it, this is a not a C project at all, but a mixed language one: C, makefile, Bash, M4 and SED. Perhaps even more. (And C of course includes its macro language.) If someone is building a C implementation from scratch (ie. starting with nothing) and testing it on sample 'C' projects, then they won't get very far with this one. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-07 21:53 +1200 |
| Message-ID | <e0oeoiFoda0U2@mid.individual.net> |
| In reply to | #91844 |
On 08/ 7/16 08:54 PM, BartC wrote: > On 07/08/2016 01:03, Rick C. Hodgin wrote: >> >> Nobody else would have to do that, Bart. You would download and install >> the source files, and then include a DLL or OBJ files which are included >> in your distributed project. You could include a readme.txt file on how >> you built it so those who want to build it can. >> >> You can also refactor the source code so it is a single source file, and >> distribute it that way. > > You've got it back to front. Probably everyone else is happy to jump > through all those hoops (perhaps because they've always had to do it and > think that's how it must be). I'm not! ./configure; make Now that's one massive hoop... -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 11:34 +0100 |
| Message-ID | <no72rk$h00$1@dont-email.me> |
| In reply to | #91846 |
On 07/08/2016 10:53, Ian Collins wrote: > On 08/ 7/16 08:54 PM, BartC wrote: >> On 07/08/2016 01:03, Rick C. Hodgin wrote: >>> >>> Nobody else would have to do that, Bart. You would download and install >>> the source files, and then include a DLL or OBJ files which are included >>> in your distributed project. You could include a readme.txt file on how >>> you built it so those who want to build it can. >>> >>> You can also refactor the source code so it is a single source file, and >>> distribute it that way. >> >> You've got it back to front. Probably everyone else is happy to jump >> through all those hoops (perhaps because they've always had to do it and >> think that's how it must be). I'm not! > > ./configure; make > > Now that's one massive hoop... On my machine that doesn't work. Because it's designed to be meaningful only on Linux or something that emulates Linux. Getting that sorted /is/ quite a big hoop. But even if it worked**, the question is WHY? What on earth does it do that absolutely REQUIRES 20,000 lines of scripting code? Is there no one willing to simplify it? If everyone ignores these issues, then sooner or later we will need 200,000 lines of scripting code (piling up layer upon layer) and no one on the planet will know what it all does. (Or perhaps people like you are secretly rubbing your hands thinking of all the extra build farms you can sell!) (**And from my experience, even when I make the attempt, it too often crashes out half way through. Or sometimes, it apparently completes - except it neglects to tell you exactly what it has produced and where it's placed it!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-08-07 12:06 +0000 |
| Message-ID | <2016Aug7.140653@mips.complang.tuwien.ac.at> |
| In reply to | #91847 |
BartC <bc@freeuk.com> writes: >On 07/08/2016 10:53, Ian Collins wrote: >> On 08/ 7/16 08:54 PM, BartC wrote: >>> On 07/08/2016 01:03, Rick C. Hodgin wrote: >>>> >>>> Nobody else would have to do that, Bart. You would download and install >>>> the source files, and then include a DLL or OBJ files which are included >>>> in your distributed project. You could include a readme.txt file on how >>>> you built it so those who want to build it can. >>>> >>>> You can also refactor the source code so it is a single source file, and >>>> distribute it that way. >>> >>> You've got it back to front. Probably everyone else is happy to jump >>> through all those hoops (perhaps because they've always had to do it and >>> think that's how it must be). I'm not! >> >> ./configure; make >> >> Now that's one massive hoop... > >On my machine that doesn't work. Because it's designed to be meaningful >only on Linux or something that emulates Linux. Actually configure scripts are typically used to deal with the differences between systems, many of which are not Linux and do not emulate Linux (if they did, much less configuration stuff would be required). Indeed, configure scripts predate Linux. >But even if it worked**, the question is WHY? What on earth does it do >that absolutely REQUIRES 20,000 lines of scripting code? Is there no one >willing to simplify it? No. That's because a configure script is not made for human consumption, but for running on the lowest common denominator shell, so that it runs on as many systems as possible. If you want something to understand, read the source file from which the configure script was generated. >(**And from my experience, even when I make the attempt, it too often >crashes out half way through. Or sometimes, it apparently completes - >except it neglects to tell you exactly what it has produced and where >it's placed it!) It's not an autoconf-generated configure script then; these tell you what files they generate. - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-07 14:10 +0100 |
| Message-ID | <87lh08n2s3.fsf@bsb.me.uk> |
| In reply to | #91847 |
BartC <bc@freeuk.com> writes: > On 07/08/2016 10:53, Ian Collins wrote: >> On 08/ 7/16 08:54 PM, BartC wrote: >>> On 07/08/2016 01:03, Rick C. Hodgin wrote: >>>> >>>> Nobody else would have to do that, Bart. You would download and install >>>> the source files, and then include a DLL or OBJ files which are included >>>> in your distributed project. You could include a readme.txt file on how >>>> you built it so those who want to build it can. >>>> >>>> You can also refactor the source code so it is a single source file, and >>>> distribute it that way. >>> >>> You've got it back to front. Probably everyone else is happy to jump >>> through all those hoops (perhaps because they've always had to do it and >>> think that's how it must be). I'm not! >> >> ./configure; make >> >> Now that's one massive hoop... > > On my machine that doesn't work. Because it's designed to be > meaningful only on Linux or something that emulates Linux. > > Getting that sorted /is/ quite a big hoop. So what are your options? (a) Write your own GC library like you have done for your own language, editor, debugger and so on. (b) Spend a fraction of that effort getting ./configure; make to work on your machine and then provide the resulting library as a contribution to the world of free software (always assuming that's not already been done). (c) Whine about how everyone else writes software on Usenet. What isn't going to happen is that people will stop using autoconf and make because you don't like them. Personally, I hate autoconf, but I don't know the problems it solves well enough to try to replace it, and it has the benefit (for me) that it just works. I suppose you could consider switching to Linux, since I've not had to run a configure script for years -- most often you just install the required pre-built package. And of you do need to run ./configure; make you'll find it probably just works. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-07 15:38 +0100 |
| Message-ID | <no7h6c$tlc$1@dont-email.me> |
| In reply to | #91853 |
On 07/08/2016 14:10, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> On my machine that doesn't work. Because it's designed to be >> meaningful only on Linux or something that emulates Linux. >> >> Getting that sorted /is/ quite a big hoop. > > So what are your options? Last time I needed to sort out something like this, it was Jacob's CCL library. That didn't use scripts, just a Make file, but I had lots of problems as I wrote at the time (some turned out to be bugs in the tools I was trying to use). Why couldn't I just compile all the .c files and link the lot? Well that is exactly what I did, and it worked perfectly. I just needed to know which files were needed, but this information was buried in the Make file so I had to use trial and error. So Make was not really needed: just some basic information - in English. > (a) Write your own GC library like you have done for your own language, > editor, debugger and so on. Sure. But I also depend on external libraries. Ones such as MSVCRT.DLL, GDI32.DLL and so on I know will be present, so they are not a problem. But what about GMP, or this GC module? Suppose I make my product have a dependency on those; the onus is now on whoever builds my project to try and source binary versions of those libraries. That is not so simple, as I found. If they try to build from sources, they then will face the same problems I did. I like to distribute my projects as C programs in a single self-contained source file**. All that's necessary is to compile that one file into an executable. Done. Unless they now need to download the sources for GMP; or for GC; or both; or maybe a half-dozen other libraries I might make use of. My project is then no longer utterly trivial to build - on Windows - but becomes a nightmare. And one I can't help with. In the case of GC, that's 500 files of which half are .c or .h files. Which ones do I need to compile for a Windows version? I don't know. This apparently classified information is only known to Make (and possibly only after running ./configure to make the makefile! I've absolutely no idea what's going on. If it doesn't work, I'm ****ed) Why not just tell me and I can sort it out myself? (** Second-best, and a bit easier for me and involving more readable code, is to supply N .c source files. This is possible by giving a link to a git directory for example. Then the instructions are really complicated: just compile the lot and link each file into the executable! It would be 'gcc *.c' if it allowed it (it doesn't on Windows). My next project will be about 30Kloc, that is a byte-code compiler, interpreter and libraries (including support for reference-counted GC, big integers and (when on Windows) some graphics and image facilities. Still a single .c file. Which builds to a single executable file that is also supplied ready-built. What could be simpler?) > (b) Spend a fraction of that effort getting ./configure; make to work on > your machine and then provide the resulting library as a contribution to > the world of free software (always assuming that's not already been > done). The one for GMP is elusive. (There is probably a version bundled within gcc - which is for gcc's own use. But so what, downloading the right gcc bundle in order to extract a single file is also a hassle.) However, why aren't binaries of popular libraries already available? The very first person who successfully manages to build one will have a copy! > > (c) Whine about how everyone else writes software on Usenet. > > What isn't going to happen is that people will stop using autoconf and > make because you don't like them. Personally, I hate autoconf, but I > don't know the problems it solves well enough to try to replace it, and > it has the benefit (for me) that it just works. > > I suppose you could consider switching to Linux, since I've not had to > run a configure script for years -- most often you just install the > required pre-built package. And of you do need to run ./configure; make > you'll find it probably just works. It's scary enough when you type 'sudo apt-get install <package>'; I've no idea what it's up to, then eventually saying M packages need downloading or updating and N hundreds more MB of space is needed. Most people will just let it get on with it. Is it doing 1x, 10x or 100x more work that than would reasonable to do what it has to do? Nobody seems to know and nobody seems to care! And it doesn't always work: I did apt-get once on a RaspBerry Pi and it was working away for 90 minutes. Then it hung. Now what? But I was trying to do something already several levels removed from what I was trying to achieve in the first place (as seems to happen in Linux). I just gave up. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 14:32 -0700 |
| Message-ID | <lny448w9ho.fsf@kst-u.example.com> |
| In reply to | #91860 |
BartC <bc@freeuk.com> writes:
[...]
> In the case of GC, that's 500 files of which half are .c or .h files.
> Which ones do I need to compile for a Windows version? I don't know.
> This apparently classified information is only known to Make (and
> possibly only after running ./configure to make the makefile! I've
> absolutely no idea what's going on. If it doesn't work, I'm ****ed)
By GC, do you mean Boehm's garbage collection package? If so, the
included README.QUICK file contains instructions for building on
Windows. But the current distribution contains only 105 *.h and *.c
files, not 500.
If GC is a typo for GCC, you've already discussed this numerous times.
[...]
> The one for GMP is elusive. (There is probably a version bundled within
> gcc - which is for gcc's own use. But so what, downloading the right gcc
> bundle in order to extract a single file is also a hassle.)
No, gcc doesn't include a bundled version of gmp. It depends on it
already being installed.
> However, why aren't binaries of popular libraries already available? The
> very first person who successfully manages to build one will have a copy!
You mean Windows binaries, right? How is that a C question? Ask
somewhere else.
--
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 | 2016-08-07 23:44 +0100 |
| Message-ID | <no8dk8$ga$1@dont-email.me> |
| In reply to | #91877 |
On 07/08/2016 22:32, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> In the case of GC, that's 500 files of which half are .c or .h files. >> Which ones do I need to compile for a Windows version? I don't know. >> This apparently classified information is only known to Make (and >> possibly only after running ./configure to make the makefile! I've >> absolutely no idea what's going on. If it doesn't work, I'm ****ed) > > By GC, do you mean Boehm's garbage collection package? If so, the > included README.QUICK file contains instructions for building on > Windows. But the current distribution contains only 105 *.h and *.c > files, not 500. It's Boehm GC. It turns out there were two different versions one inside the other (probably due to .tar/.gz files being fiddly to unpack under Windows). I deleted one version, but probably the wrong one as I got nowhere with the make files. If I reinstall the other 7.2 version, I can get somewhere if I use MSVC. (It produces gctest.exe and gc.lib. I don't know what that means at the minute, and I don't use MSVC. To be useful to me I need .dll files in 32-bit and 64-bit versions, and with C interfaces. There was a lot of mention of C++ which doesn't bode well. But completing the make means I can see what files are involved and I can try a manual build. Then I might be in a position to produce build instructions in plain English that will work with any C compiler.) What's interesting however is that this NMAKE didn't need 'configure' to work. So why does Linux need it? And what exactly DOES it do? Apparently, nothing important! 20,000 pointless lines just as I thought. >> The one for GMP is elusive. (There is probably a version bundled within >> gcc - which is for gcc's own use. But so what, downloading the right gcc >> bundle in order to extract a single file is also a hassle.) > > No, gcc doesn't include a bundled version of gmp. It depends on it > already being installed. gcc/TDM for Windows includes libgmp-3.dll. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 16:12 -0700 |
| Message-ID | <lnpopkw4v5.fsf@kst-u.example.com> |
| In reply to | #91887 |
BartC <bc@freeuk.com> writes:
> On 07/08/2016 22:32, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> In the case of GC, that's 500 files of which half are .c or .h files.
>>> Which ones do I need to compile for a Windows version? I don't know.
>>> This apparently classified information is only known to Make (and
>>> possibly only after running ./configure to make the makefile! I've
>>> absolutely no idea what's going on. If it doesn't work, I'm ****ed)
>>
>> By GC, do you mean Boehm's garbage collection package? If so, the
>> included README.QUICK file contains instructions for building on
>> Windows. But the current distribution contains only 105 *.h and *.c
>> files, not 500.
>
> It's Boehm GC. It turns out there were two different versions one inside
> the other (probably due to .tar/.gz files being fiddly to unpack under
> Windows). I deleted one version, but probably the wrong one as I got
> nowhere with the make files.
I downloaded
http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz
It does not have "two different versions one inside the other".
I have no idea how you concluded that there are 500 .h and .c files;
there are only 105. If unpacking *.tar.gz files is difficult under
Windows, that's a pity; I suggest you either do something about it
or complain to someone can.
> If I reinstall the other 7.2 version, I can get somewhere if I use MSVC.
>
> (It produces gctest.exe and gc.lib. I don't know what that means at the
> minute, and I don't use MSVC. To be useful to me I need .dll files in
> 32-bit and 64-bit versions, and with C interfaces. There was a lot of
> mention of C++ which doesn't bode well.
>
> But completing the make means I can see what files are involved and I
> can try a manual build. Then I might be in a position to produce build
> instructions in plain English that will work with any C compiler.)
>
> What's interesting however is that this NMAKE didn't need 'configure' to
> work. So why does Linux need it? And what exactly DOES it do?
> Apparently, nothing important! 20,000 pointless lines just as I thought.
Ah, so you *did* get it to build on Windows. What are you still
complaining about?
Boehm's GC apparently is written in a way that you can build it with
"nmake", and it doesn't need the "configure" script. As far as I can
tell, nmake is available only on Windows, so I need to use either
"configure" or some substitute to build Boehm's GC from source on my
Linux system.
autoconf, which generate the "configure" script, is an elaborate system
that's designed to work with a variety of different systems. The Unix
ecosystem used to be as lot more varied than it is now. The initial
release was in 1991, when it wasn't even possible to assume an ANSI C
compiler and standard library. It has a *lot* of code that checks for
things like the return types of standard library functions -- checks
that are no longer needed if you can assume C89 or better.
Is it time to simplify autoconf so it doesn't worry about all that old
stuff? Maybe -- but it does it all automatically so the extra work it
does doesn't bother me. Perhaps trimming it down isn't worth the
effort. Perhaps there are still enough variations in the real world
that it's still sometimes necessary.
So to support building Boehm's GC on Linux, it uses the same autoconf
mechanism that's used for hundreds of other software packages. Setting
it up is fairly straightforward for the maintainer and trivial for the
end user. It works. Users who need to install it from source can type
one or two commands to configure and install it. There's no reason for
them to care that "configure" is doing some extra work that might no
longer be necessary.
>>> The one for GMP is elusive. (There is probably a version bundled within
>>> gcc - which is for gcc's own use. But so what, downloading the right gcc
>>> bundle in order to extract a single file is also a hassle.)
>>
>> No, gcc doesn't include a bundled version of gmp. It depends on it
>> already being installed.
>
> gcc/TDM for Windows includes libgmp-3.dll.
That's nice. I just Googled it. It's called "tdm-gcc", and
it's "A compiler suite for 32- and 64-bit Windows based on the
GNU toolchain". It's not just gcc. (I trust I don't need to
explain yet again what "gcc" is and what it isn't.) gcc itself
still doesn't include a bundled version of gmp. tdm-gcc apparently
includes bundled versions of gcc, gmp, and other packages.
--
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 | 2016-08-08 01:42 +0100 |
| Message-ID | <no8kir$h6m$1@dont-email.me> |
| In reply to | #91892 |
On 08/08/2016 00:12, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > I downloaded > http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz > It does not have "two different versions one inside the other". > I have no idea how you concluded that there are 500 .h and .c files; > there are only 105. There were ~500 files of all kinds in both versions together, of which 258 were .c or .h. >> If I reinstall the other 7.2 version, I can get somewhere if I use MSVC. >> >> (It produces gctest.exe and gc.lib. I don't know what that means at the >> minute, and I don't use MSVC. To be useful to me I need .dll files in >> 32-bit and 64-bit versions, and with C interfaces. There was a lot of >> mention of C++ which doesn't bode well. >> >> But completing the make means I can see what files are involved and I >> can try a manual build. Then I might be in a position to produce build >> instructions in plain English that will work with any C compiler.) >> >> What's interesting however is that this NMAKE didn't need 'configure' to >> work. So why does Linux need it? And what exactly DOES it do? >> Apparently, nothing important! 20,000 pointless lines just as I thought. > > Ah, so you *did* get it to build on Windows. What are you still > complaining about? I've made progress. > Boehm's GC apparently is written in a way that you can build it with > "nmake", and it doesn't need the "configure" script. As far as I can > tell, nmake is available only on Windows, so I need to use either > "configure" or some substitute to build Boehm's GC from source on my > Linux system. No. I still don't see what the big deal is in building a project that comprises modules A, B and C. You compile A.c, B.c and C.c and link the resulting object files. All you need is a list of the files A.c, B.c and C.c. You don't really need Make, especially for a one-off build of a distribution (as opposed to periodic building as part of normal development). And you don't need a completely over-the-top script. 20 lines or 200 lines might be plausible; 20,000 lines isn't). If there are special requirements (for example a module or header needs to be synthesised according to environment), then that can be carefully explained in the build instructions - in English. Once you have that, then there can be optional other solutions on top. Putting instructions in English is an incentive to keep things short and simple, and to find alternative solutions as necessary to make that possible. There is no such incentive when there is no upper limit on size or complexity of a script or makefile. > autoconf, which generate the "configure" script, is an elaborate system > that's designed to work with a variety of different systems. The Unix > ecosystem used to be as lot more varied than it is now. The initial > release was in 1991, when it wasn't even possible to assume an ANSI C > compiler and standard library. It has a *lot* of code that checks for > things like the return types of standard library functions -- checks > that are no longer needed if you can assume C89 or better. > > Is it time to simplify autoconf so it doesn't worry about all that old > stuff? Maybe -- but it does it all automatically so the extra work it > does doesn't bother me. Perhaps trimming it down isn't worth the > effort. Perhaps there are still enough variations in the real world > that it's still sometimes necessary. > > So to support building Boehm's GC on Linux, it uses the same autoconf > mechanism that's used for hundreds of other software packages. Setting > it up is fairly straightforward for the maintainer and trivial for the > end user. But it is unreasonable to expect people to go out of their way to install MSYS or CYGWIN or whatever is needed to make it work under Windows Although it in this case, that is only needed to compile with gcc, if I read the notes properly, and not with MSVC. (However it is worth bearing in mind that a full MSVC installation with Visual Studio is probably bigger than Cygwin.) > It works. Users who need to install it from source can type > one or two commands to configure and install it. There's no reason for > them to care that "configure" is doing some extra work that might no > longer be necessary. When it crashes out in the middle then it starts to matter... >> gcc/TDM for Windows includes libgmp-3.dll. > > That's nice. I just Googled it. It's called "tdm-gcc", and > it's "A compiler suite for 32- and 64-bit Windows based on the > GNU toolchain". It's not just gcc. (I trust I don't need to > explain yet again what "gcc" is and what it isn't.) gcc itself > still doesn't include a bundled version of gmp. tdm-gcc apparently > includes bundled versions of gcc, gmp, and other packages. I don't think gmp is officially bundled. libgmp-3.dll is present but that's it. Not .a library (unless it's libigmpagnt.a, but that's only 4KB), and no gmp.h is included. The .dll might be there for the compiler's use. There are enough ifs and buts about this library that I can't rely on it. (But with some effort, I could make it optional.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-07 18:56 -0700 |
| Message-ID | <lneg60vxaf.fsf@kst-u.example.com> |
| In reply to | #91900 |
BartC <bc@freeuk.com> writes:
> On 08/08/2016 00:12, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>> I downloaded
>> http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz
>> It does not have "two different versions one inside the other".
>> I have no idea how you concluded that there are 500 .h and .c files;
>> there are only 105.
>
> There were ~500 files of all kinds in both versions together, of which
> 258 were .c or .h.
What on Earth are you talking about? What do you mean by "both
versions"?
$ ls -l gc-7.4.4.tar.gz
-rw-r--r-- 1 kst kst 1103245 Jun 8 08:34 gc-7.4.4.tar.gz
$ tar xf gc-7.4.4.tar.gz
$ find gc-7.4.4 -type f | wc -l
201
$ find gc-7.4.4 -type f -name '*.[ch]' | wc -l
105
$
[...]
> But it is unreasonable to expect people to go out of their way to
> install MSYS or CYGWIN or whatever is needed to make it work under Windows
You have difficulty building software from source on Windows.
What do you expect us to do about it, especially when you reject
anything we suggest? It's not a C programming issue. Please find
someplace else 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-08 10:20 +0100 |
| Message-ID | <no9itc$pil$1@dont-email.me> |
| In reply to | #91909 |
On 08/08/2016 02:56, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 08/08/2016 00:12, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >> >>> I downloaded >>> http://www.hboehm.info/gc/gc_source/gc-7.4.4.tar.gz >>> It does not have "two different versions one inside the other". >>> I have no idea how you concluded that there are 500 .h and .c files; >>> there are only 105. >> >> There were ~500 files of all kinds in both versions together, of which >> 258 were .c or .h. > > What on Earth are you talking about? What do you mean by "both > versions"? Christ. It was a minor point. Forget it. What can it matter if there were 100 files or 200 files? These kinds of distributions insist in keeping details of what file is what a secret because they expect the build to be done automatically. It apparently only matters to people like me who like to understand and to be on top of the process. But in this case it enabled you to detect there might have been a problem. Perhaps having an idea of how many files there might be, is a benefit after all. (The first attempts to unpack, created one version in \GC and another in \GC\GC_7.2 or something. That's all, just a minor mishap because the 7-zip program I use is rubbish, and the distinction between .gz and .tar is confusing. Also because, if the original directory was X and contained files A,B,C, then a .zip will typically contain the top-level files A,B,C, while .tar.gz will contain X and needs to be unpacked into the root directory not one of my choice such as Y. Furthermore, unpacking .tar.gz is two-step process, each requiring me to enter the name of a directory, and usually one directory level deeper than I need. As I said, confusing. And that's before I get to the build instructions. Yet this is what is used under Linux so it must be superior to everything else on the planet. (Nine times out of ten that I encounter .tar/.gz, .bz2 whatever, I give it a miss because it's so much hassle).) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-08 09:39 -0700 |
| Message-ID | <lnmvknusew.fsf@kst-u.example.com> |
| In reply to | #91931 |
BartC <bc@freeuk.com> writes:
> On 08/08/2016 02:56, Keith Thompson wrote:
[...]
>> What on Earth are you talking about? What do you mean by "both
>> versions"?
>
> Christ. It was a minor point. Forget it.
I'd be happy to ...
[several paragraphs snipped]
... but you keep whining about it. Here's my suggestion.
Rather than complaining at great length that you don't like the
way this stuff works, find an appropriate forum (strong hint: it's
not comp.lang.c unless it's directly relevant to C programming)
and *ask* about it.
I'll reply in more detail by e-mail.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-08 02:30 +0100 |
| Message-ID | <87wpjskpy6.fsf@bsb.me.uk> |
| In reply to | #91860 |
BartC <bc@freeuk.com> writes: <snip> > In the case of GC, that's 500 files of which half are .c or .h > files. What did you download? <snip> > It's scary enough when you type 'sudo apt-get install <package>'; I've > no idea what it's up to, then eventually saying M packages need > downloading or updating and N hundreds more MB of space is > needed. Installing GC (the run-time library and the 'dev' package) downloads about 0.4 MB and expands to use 1.3 MB in total. > Most people will just let it get on with it. > > Is it doing 1x, 10x or 100x more work that than would reasonable to do > what it has to do? Nobody seems to know and nobody seems to care! Yes, people both know and care. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web