Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #381174 > unrolled thread
| Started by | bart <bc@freeuk.com> |
|---|---|
| First post | 2024-01-29 16:03 +0000 |
| Last post | 2024-02-12 02:18 +0000 |
| Articles | 20 on this page of 415 — 26 participants |
Back to article view | Back to comp.lang.c
Experimental C Build System bart <bc@freeuk.com> - 2024-01-29 16:03 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-30 00:57 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-29 17:38 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-30 09:06 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 15:23 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 08:36 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-31 19:12 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 00:44 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 01:45 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 04:46 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 11:52 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 16:50 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 17:57 +0000
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:22 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-01-31 16:41 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-01-31 19:01 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 20:25 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 09:39 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 11:31 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 16:11 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 17:33 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 18:34 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-01 22:23 +0200
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 20:55 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 13:10 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 22:38 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 00:55 +0200
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:31 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:08 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 09:02 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 15:28 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 15:49 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 16:53 +0200
Stu Feldman (Was: Experimental C Build System) gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-02 16:29 +0000
Re: Stu Feldman (Was: Experimental C Build System) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 17:29 +0000
Re: Stu Feldman (Was: Experimental C Build System) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-04 05:44 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 13:47 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 15:57 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 15:18 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 17:44 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 18:26 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:45 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-03 21:24 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 13:19 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 22:12 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:29 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 12:02 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:25 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:47 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 19:52 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 19:58 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:52 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-03 14:52 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 14:59 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:51 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 11:08 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 15:44 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 16:03 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 17:02 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:29 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:31 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 22:11 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 16:24 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 01:19 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 17:51 -0800
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-04 14:07 +1100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:01 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 04:56 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 21:36 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 21:41 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:44 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 15:50 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:27 +0100
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:52 -0800
Re: Experimental C Build System Kees Nuyt <k.nuyt@nospam.demon.nl> - 2024-02-05 17:57 +0100
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 09:17 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 19:11 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:29 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 06:43 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:51 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-03 21:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 21:39 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 14:23 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 13:48 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 14:16 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 18:17 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 20:12 +0000
Re: Experimental C Build System Jim Jackson <jj@franjam.org.uk> - 2024-02-04 16:13 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:08 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-04 18:22 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 13:53 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 14:01 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:36 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:46 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 23:29 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 15:32 -0800
Re: Experimental C Build System Jim Jackson <jj@franjam.org.uk> - 2024-02-05 17:37 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 18:03 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 18:42 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:25 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 21:31 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:40 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 22:29 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 14:39 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 22:47 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-06 00:03 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 19:16 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 00:07 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 16:10 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 10:41 -0600
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-05 18:13 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-06 23:41 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 09:56 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 11:10 +0000
Re: Experimental C Build System Dan Purgert <dan@djph.net> - 2024-02-07 11:13 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:50 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:05 +0000
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-07 23:46 +1100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 15:09 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-07 14:21 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 10:11 -0600
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:46 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 21:53 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 14:54 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 16:15 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-07 17:34 +0000
Re: Experimental C Build System [Ben] olcott <polcott2@gmail.com> - 2024-02-07 22:50 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 09:40 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 11:55 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 12:32 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 16:35 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-08 16:31 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 21:24 +0100
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-08 16:50 +0000
Re: Experimental C Build System Dan Purgert <dan@djph.net> - 2024-02-08 17:04 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-08 17:10 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 17:25 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 23:30 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-08 17:38 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-08 21:30 +0100
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 00:58 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 01:14 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-09 01:18 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 01:27 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 01:30 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 10:32 +0000
Re: Experimental C Build System Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-09 13:16 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 02:07 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 15:49 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 17:13 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 18:24 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 10:34 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 18:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 20:41 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 21:56 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 22:43 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 23:12 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 23:47 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 00:28 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 15:41 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 23:53 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 00:16 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 16:33 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 02:26 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-10 02:47 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 20:17 +0200
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-10 21:02 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 20:09 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 22:43 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-10 19:51 +0200
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-09 18:25 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 20:55 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:06 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-09 13:15 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-09 22:09 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-10 15:24 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:04 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-09 09:21 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 17:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 23:29 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:31 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 19:24 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:44 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:30 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 10:12 -0600
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-07 08:40 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-07 12:24 -0600
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 01:45 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:17 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-04 20:41 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:46 -0800
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-05 06:48 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 11:20 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 13:33 -0800
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 21:57 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 23:20 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-05 15:41 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-06 01:48 +0000
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-06 00:18 +0000
Re: Experimental C Build System gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 06:00 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 22:46 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 15:57 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-05 13:02 +0100
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 14:50 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 22:51 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 23:18 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 00:16 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 14:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 14:40 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 16:59 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 19:20 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 20:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 20:34 +0000
Re: Experimental C Build System Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-06 20:49 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-06 13:07 -0800
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 21:39 +0000
Re: Experimental C Build System Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-02-07 15:02 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 20:36 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 20:48 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 21:15 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 23:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 23:58 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-08 01:33 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 01:34 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-08 01:50 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-08 02:17 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 22:48 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 23:44 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 21:09 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-06 21:43 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:23 -0800
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 00:51 +0100
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-07 02:18 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 04:21 +0100
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-07 07:17 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-07 12:59 +0100
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-07 23:53 +1100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-07 15:45 +0200
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-08 12:56 +1100
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-08 17:22 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-06 00:07 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 10:08 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-09 11:44 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-09 21:03 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 22:34 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 22:29 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:28 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:03 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 17:42 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 02:43 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 19:03 -0800
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 10:54 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:16 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 16:09 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:32 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 02:36 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 00:53 -0800
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 13:51 -0800
Re: Experimental C Build System Richard Damon <richard@damon-family.org> - 2024-02-03 17:56 -0500
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 07:52 -0800
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 06:18 -0800
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-02 03:22 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 11:13 +0000
Re: Experimental C Build System "Gary R. Schmidt" <grschmidt@acm.org> - 2024-02-03 00:25 +1100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 13:29 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 10:47 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 15:45 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 16:26 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 14:39 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-03 16:26 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 17:11 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-06 13:59 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 13:14 +0100
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-06 14:32 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-06 14:16 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-06 17:02 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-06 20:31 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 14:14 +0000
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-02 16:43 +0200
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 15:18 +0000
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-02 20:43 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 20:16 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 16:31 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 17:00 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 17:31 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 10:36 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 19:52 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 20:21 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 21:09 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 13:15 -0800
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 15:13 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:23 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 21:51 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:31 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 12:16 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 17:59 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 19:35 +0000
Re: Experimental C Build System tTh <tth@none.invalid> - 2024-02-03 21:57 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 18:48 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 20:18 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-04 20:55 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-07 02:57 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-07 03:18 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 15:27 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-07 15:48 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-07 16:30 +0000
Re: Experimental C Build System vallor <vallor@cultnix.org> - 2024-02-08 00:39 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 21:59 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 09:42 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-07 10:40 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-07 15:37 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-04 22:51 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 23:11 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-05 13:42 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-05 14:59 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-05 15:45 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-05 11:25 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 22:46 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:43 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:42 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:53 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 14:02 -0800
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 10:48 -0600
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 17:29 +0000
Re: Experimental C Build System candycanearter07 <no@thanks.net> - 2024-02-05 11:36 -0600
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 14:04 -0800
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 18:54 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 06:04 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 22:13 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 06:43 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 00:02 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 08:47 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-03 06:30 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 11:17 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 14:02 -0800
[meta] Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-03 15:04 +0100
Re: [meta] Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 07:19 -0800
Re: [meta] Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-04 05:29 +0100
Re: [meta] Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 05:37 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 16:26 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:30 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 11:05 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 21:18 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-04 15:50 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 00:26 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 00:35 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-02 11:13 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-02 10:54 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 14:15 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 01:46 +0100
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 16:20 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 21:34 +0000
Re: Experimental C Build System Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-01 16:09 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 17:32 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 19:25 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 19:51 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 12:12 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 12:43 -0800
Re: Experimental C Build System Michael S <already5chosen@yahoo.com> - 2024-02-01 22:36 +0200
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 23:09 +0100
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:32 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 21:17 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 09:48 +0100
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 11:49 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 21:39 +0000
Re: Experimental C Build System Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:24 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:38 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 23:53 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 23:14 +0100
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-30 09:17 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-30 12:09 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 15:25 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-30 17:50 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 03:14 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-31 20:38 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 13:46 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 14:06 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-05 14:48 +0000
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-05 15:23 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-30 16:46 -0800
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 03:13 +0000
Re: Experimental C Build System Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-31 03:23 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 08:47 +0100
Re: Experimental C Build System Spiros Bousbouras <spibou@gmail.com> - 2024-01-31 11:02 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-01-31 15:31 +0100
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:13 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 23:00 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:29 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 03:07 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 15:00 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:40 +0000
system(3) (was: Re: Experimental C Build System) vallor <vallor@cultnix.org> - 2024-02-01 08:15 +0000
Re: Experimental C Build System Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 23:02 +0000
Re: Experimental C Build System scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:33 +0000
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 15:11 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:55 +0100
Re: Experimental C Build System Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:42 +0100
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 12:19 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-01 14:29 +0000
Re: Experimental C Build System David Brown <david.brown@hesbynett.no> - 2024-02-01 16:43 +0100
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 01:05 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 11:54 +0000
Re: Experimental C Build System Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 07:17 -0800
Re: Experimental C Build System Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 15:54 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 16:05 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:39 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-03 22:19 +0000
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:56 -0800
Re: Experimental C Build System "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 20:57 -0800
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-01-31 20:36 +0000
Re: Experimental C Build System thiago <thiago.adams@gmail.com> - 2024-02-07 20:36 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-08 13:50 +0000
Re: Experimental C Build System thiago <thiago.adams@gmail.com> - 2024-02-07 20:42 +0000
Re: Experimental C Build System bart <bc@freeuk.com> - 2024-02-12 02:18 +0000
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-04 20:18 +0000 |
| Message-ID | <uporeb$3qev4$1@dont-email.me> |
| In reply to | #381754 |
On 04/02/2024 17:48, David Brown wrote: > On 03/02/2024 20:35, bart wrote: >> It is Windows that places more store by file extensions, which Linux >> people say is a bad thing. >> > > Windows is too dependent on them, and too trusting. >> But above you say that is the advantage of Linux. > > Yes, it's a hands-down win for Linux (and other *nix) in this aspect. Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker script, and ASSUMES that .s is an assembly source file; INCORRECT assumptions. I think I'm starting to understand the rules: whatever Windows does is always wrong, and whatever Linux does is always right! To be clear, this is the behaviour of /my/ applications, which work the same way on Windows /or/ Linux, that work primarily work on one type of file, that assume that file type no matter what the extension. BOTH methods can be problematic if you deliberately or accidentally mix up file types and extensions. >> And that's only when I run it under Linux. That's because under Linux, >> 'filename' and 'filename.' are distinct files; the "." is part of the >> file name, not a notional separator. >> > > Of course it is. It's simple and consistent. > > In Windows, it is sometimes part of a file name (when it is not the last > period in the name), sometimes a magical character that appears or > disappears (when the file ends in a period), and sometimes it delimits a > file extension. It probably still needs to be a notional dot for backwards compatibility over decades. The first two DEC systems I used had 6.3 filenames, storing 'sixbit' characters in 1.5 words for 36 bits, or using 'radix-50' in 3 words for 16 bits. You can see there is nowhere to put the dot. That was carried over to DOS's 8.3 filename. This dot then was really a virtual separator that did not need storing, any more than you need to store the dot in the ieee754 representation of 73.945. It has given very little trouble, and has the huge advantage that you can have default extensions on input files with no ambiguity. Let me guess: Unix allows you to have numbers like 73.945.112, while 73. is a different value from 73? Cool.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-04 20:55 +0000 |
| Message-ID | <QQSvN.294647$Wp_8.94897@fx17.iad> |
| In reply to | #381757 |
bart <bc@freeuk.com> writes: >On 04/02/2024 17:48, David Brown wrote: >> On 03/02/2024 20:35, bart wrote: > >>> It is Windows that places more store by file extensions, which Linux >>> people say is a bad thing. >>> >> >> Windows is too dependent on them, and too trusting. > >>> But above you say that is the advantage of Linux. >> >> Yes, it's a hands-down win for Linux (and other *nix) in this aspect. > >Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker I've never seen a '.x ' suffix. Ever. And I use linker scripts regularly. >script, and ASSUMES that .s is an assembly source file; The command is well documented. It assumes nothing. It (cc, the compiler driver command) will simply pass files with a .s suffix to the assembler, and the assembler will, correctly, treat it as assembler source. If it's not, that is the problem of RTFM by the user. It is definitely not the problem of the toolset (cc) or the assembler (which doesn't care what suffix is used).
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-02-07 02:57 +0000 |
| Message-ID | <upurj2$14cqf$1@dont-email.me> |
| In reply to | #381758 |
On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal) wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>: > bart <bc@freeuk.com> writes: >>On 04/02/2024 17:48, David Brown wrote: >>> On 03/02/2024 20:35, bart wrote: >> >>>> It is Windows that places more store by file extensions, which Linux >>>> people say is a bad thing. >>>> >>> >>> Windows is too dependent on them, and too trusting. >> >>>> But above you say that is the advantage of Linux. >>> >>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect. >> >>Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker > > I've never seen a '.x ' suffix. Ever. And I use linker scripts > regularly. This was the first I'd heard about them in this context, but Open Network Computing's RPC (ONCRPC, was SunRPC) does use .x files for its RPC specifications. ONCRPC is a system for generating C stubs for network services, and it is (was?) also used to specify UNIX services like NFS and NIS. The Sun of yore were, indeed, good denizens of the Net. (So, crossposting conditions satisfied...I think?) Anyway, if you have the "standard" .x files installed on Linux Mint, they live in /usr/include/rpcsvc/ Also, there are linker scripts that end in ".x" which on my system live here: /usr/lib/x86_64-linux-gnu/ldscripts/ Fascinating to read -- and way over my head. (The man page for GNU ld says they are "AT&T's Link Editor Command Language syntax".) I'm not sure how often an average programmer would look around in there. In any event, the ".x" files in that directory are in the minority... -- -v (cue music for "The X Files") $ locate -r "\.x$"
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-07 03:18 +0000 |
| Message-ID | <upusql$158lc$1@dont-email.me> |
| In reply to | #381943 |
On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote: > Also, there are linker scripts that end in ".x" > which on my system live here: > > /usr/lib/x86_64-linux-gnu/ldscripts/ > > Fascinating to read -- and way over my head. (The man page for GNU ld > says they are "AT&T's Link Editor Command Language syntax".) I'm not > sure how often an average programmer would look around in there. Documentation on the script language here <https://sourceware.org/binutils/docs/ld/Scripts.html>. An obvious example of the need for a custom linker script would be building the Linux kernel, where you need a special format for the resulting binary that can be loaded by a bootloader. I had a look through the Linux sources, and there is (no big surprise) a different version of this script for each architecture, which is supposed to have the name arch/«architecture»/kernel/vmlinux.lds. I think this generated from the corresponding vmlinux.lds.S file in the source tree.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-07 15:27 +0000 |
| Message-ID | <mjNwN.343223$xHn7.317669@fx14.iad> |
| In reply to | #381944 |
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>
>> Also, there are linker scripts that end in ".x"
>> which on my system live here:
>>
>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>
>> Fascinating to read -- and way over my head. (The man page for GNU ld
>> says they are "AT&T's Link Editor Command Language syntax".) I'm not
>> sure how often an average programmer would look around in there.
>
>Documentation on the script language here
><https://sourceware.org/binutils/docs/ld/Scripts.html>.
>
>An obvious example of the need for a custom linker script would be
>building the Linux kernel, where you need a special format for the
>resulting binary that can be loaded by a bootloader.
Indeed, that's been my primary use of custome linker scripts since
1989. Various operating systems, hypervisors, and even today for
processor firmware. Mainly we used the .ld suffix for such
scripts.
partial example for a bare-metal hypervisor written in C++:
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(dvmmstart)
SECTIONS
{
. = 0xffff808000000000;
percpu.data : {
*(percpu.data)
}
. = 0xffff830000100000;
_start = .;
. = ALIGN(16);
_stext = .;
.text : {
*(inittext)
*(.text)
*(.text.*)
*(.gnu.linkonce.t*)
}
_etext = .;
. = ALIGN(32);
_srodata = .;
.rodata : {
*(.rodata)
*(.rodata.*)
*(.gnu.linkonce.r*)
*(.got)
*(.got.*)
__CTOR_LIST__ = .;
LONG((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
*(.ctors)
LONG(0)
__CTOR_END__ = .;
__DTOR_LIST__ = .;
LONG((__DTOR_END__ - __DTOR_LIST__) / 8 - 2)
*(.dtors)
LONG(0)
__DTOR_END__ = .;
}
_erodata = .;
. = ALIGN(32);
_sdata = .;
.data : {
*(.data)
*(.data.*)
*(.gnu.linkonce.d*)
}
_edata = .;
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-07 15:48 +0000 |
| Message-ID | <uq08nh$1fvu8$2@dont-email.me> |
| In reply to | #381984 |
On 07/02/2024 15:27, Scott Lurndal wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>>
>>> Also, there are linker scripts that end in ".x"
>>> which on my system live here:
>>>
>>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>>
>>> Fascinating to read -- and way over my head. (The man page for GNU ld
>>> says they are "AT&T's Link Editor Command Language syntax".) I'm not
>>> sure how often an average programmer would look around in there.
>>
>> Documentation on the script language here
>> <https://sourceware.org/binutils/docs/ld/Scripts.html>.
>>
>> An obvious example of the need for a custom linker script would be
>> building the Linux kernel, where you need a special format for the
>> resulting binary that can be loaded by a bootloader.
>
> Indeed, that's been my primary use of custome linker scripts since
> 1989. Various operating systems, hypervisors, and even today for
> processor firmware. Mainly we used the .ld suffix for such
> scripts.
>
> partial example for a bare-metal hypervisor written in C++:
>
> OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> OUTPUT_ARCH(i386:x86-64)
>
> ENTRY(dvmmstart)
>
> SECTIONS
> {
> . = 0xffff808000000000;
> percpu.data : {
> *(percpu.data)
> }
> . = 0xffff830000100000;
>
> _start = .;
>
> . = ALIGN(16);
> _stext = .;
> .text : {
> *(inittext)
> *(.text)
> *(.text.*)
> *(.gnu.linkonce.t*)
> }
> _etext = .;
>
> . = ALIGN(32);
> _srodata = .;
> .rodata : {
> *(.rodata)
> *(.rodata.*)
> *(.gnu.linkonce.r*)
> *(.got)
> *(.got.*)
>
> __CTOR_LIST__ = .;
> LONG((__CTOR_END__ - __CTOR_LIST__) / 8 - 2)
> *(.ctors)
> LONG(0)
> __CTOR_END__ = .;
>
> __DTOR_LIST__ = .;
> LONG((__DTOR_END__ - __DTOR_LIST__) / 8 - 2)
> *(.dtors)
> LONG(0)
> __DTOR_END__ = .;
> }
> _erodata = .;
>
> . = ALIGN(32);
> _sdata = .;
> .data : {
> *(.data)
> *(.data.*)
> *(.gnu.linkonce.d*)
> }
> _edata = .;
>
So what the hell is that? What does it mean? How am i supposed to fix it
if it goes wrong?
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-07 16:30 +0000 |
| Message-ID | <eeOwN.308695$7sbb.80772@fx16.iad> |
| In reply to | #381990 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 07/02/2024 15:27, Scott Lurndal wrote: >> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote: >>> >> >So what the hell is that? What does it mean? How am i supposed to fix it >if it goes wrong? I suspect you've been the internet long enough to have seen the phrase RTFM...
[toc] | [prev] | [next] | [standalone]
| From | vallor <vallor@cultnix.org> |
|---|---|
| Date | 2024-02-08 00:39 +0000 |
| Message-ID | <uq17sq$1h0p8$1@dont-email.me> |
| In reply to | #381998 |
On Wed, 07 Feb 2024 16:30:02 GMT, scott@slp53.sl.home (Scott Lurndal) wrote in <eeOwN.308695$7sbb.80772@fx16.iad>: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>On 07/02/2024 15:27, Scott Lurndal wrote: >>> Lawrence D'Oliveiro <ldo@nz.invalid> writes: >>>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote: >>>> > >>> >>So what the hell is that? What does it mean? How am i supposed to fix it >>if it goes wrong? > > I suspect you've been the internet long enough to have seen the > phrase RTFM... He quoted the link to the documentation that Lawrence provided (thank you, Lawrence). -- -v
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 21:59 +0100 |
| Message-ID | <uq0qv4$1j1v4$6@dont-email.me> |
| In reply to | #381990 |
On 07/02/2024 16:48, Malcolm McLean wrote:
> On 07/02/2024 15:27, Scott Lurndal wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> On Wed, 7 Feb 2024 02:57:39 -0000 (UTC), vallor wrote:
>>>
>>>> Also, there are linker scripts that end in ".x"
>>>> which on my system live here:
>>>>
>>>> /usr/lib/x86_64-linux-gnu/ldscripts/
>>>>
>>>> Fascinating to read -- and way over my head. (The man page for GNU ld
>>>> says they are "AT&T's Link Editor Command Language syntax".) I'm not
>>>> sure how often an average programmer would look around in there.
>>>
>>> Documentation on the script language here
>>> <https://sourceware.org/binutils/docs/ld/Scripts.html>.
>>>
>>> An obvious example of the need for a custom linker script would be
>>> building the Linux kernel, where you need a special format for the
>>> resulting binary that can be loaded by a bootloader.
>>
>> Indeed, that's been my primary use of custome linker scripts since
>> 1989. Various operating systems, hypervisors, and even today for
>> processor firmware. Mainly we used the .ld suffix for such
>> scripts.
>>
>> partial example for a bare-metal hypervisor written in C++:
>>
>> OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
>> OUTPUT_ARCH(i386:x86-64)
>>
>> ENTRY(dvmmstart)
>>
>> SECTIONS
>> {
>> . = 0xffff808000000000;
>> percpu.data : {
>> *(percpu.data)
>> }
>> . = 0xffff830000100000;
>>
>> _start = .;
>>
>> . = ALIGN(16);
>> _stext = .;
>> .text : {
>> *(inittext)
>> *(.text)
>> *(.text.*)
>> *(.gnu.linkonce.t*)
>> }
>> _etext = .;
<snip>
> So what the hell is that? What does it mean? How am i supposed to fix it
> if it goes wrong?
It's all pretty straightforward if you are willing to spend a little
effort learning it.
But you can also consider it as just "under the bonnet magic" that the
compiler and linker know about and get right - that will be fine for the
kind of things you do. (If it were not, then you would already know
about linker scripts.) You don't need to know how /everything/ works in
order to use a tool.
And if you are curious, the binutils ld manual is online.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 09:42 +0100 |
| Message-ID | <upvfqd$1bqi4$1@dont-email.me> |
| In reply to | #381943 |
On 07/02/2024 03:57, vallor wrote: > On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal) > wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>: > >> bart <bc@freeuk.com> writes: >>> On 04/02/2024 17:48, David Brown wrote: >>>> On 03/02/2024 20:35, bart wrote: >>> >>>>> It is Windows that places more store by file extensions, which Linux >>>>> people say is a bad thing. >>>>> >>>> >>>> Windows is too dependent on them, and too trusting. >>> >>>>> But above you say that is the advantage of Linux. >>>> >>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect. >>> >>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker >> >> I've never seen a '.x ' suffix. Ever. And I use linker scripts >> regularly. > > This was the first I'd heard about them in this context, but Open > Network Computing's RPC (ONCRPC, was SunRPC) does use .x files > for its RPC specifications. > > ONCRPC is a system for generating C stubs for network > services, and it is (was?) also used to specify > UNIX services like NFS and NIS. The Sun of yore > were, indeed, good denizens of the Net. (So, crossposting > conditions satisfied...I think?) > > Anyway, if you have the "standard" .x files > installed on Linux Mint, they live in > > /usr/include/rpcsvc/ > > Also, there are linker scripts that end in ".x" > which on my system live here: > > /usr/lib/x86_64-linux-gnu/ldscripts/ > > Fascinating to read -- and way over my head. (The > man page for GNU ld says they are > "AT&T's Link Editor Command Language syntax".) I'm > not sure how often an average programmer would look > around in there. > > In any event, the ".x" files in that directory are in > the minority... > If you look in that directory, you'll see all the files are ".x<flags>", where <flags> are letters. So you get ".x", ".xbn", ".xc", ".xce", and a dozen other combinations. I don't know the details of the flags, but they generally refer to different arrangements of code and data (for example, merging read-only data and executable code, or keeping them separate). There's no doubt that ".x", and ".x<flags>", are common extensions for linker files, but that they do not act as file extensions in the same way as for other source code. Instead, they are sets of flags. (That's why gcc treats any unknown extension as a linker file.) (Note to Bart - I am not saying I think this is a good idea - I am saying how it is.) I think most people writing their own linker scripts use different file extensions - I use ".ld" myself.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-07 10:40 +0000 |
| Message-ID | <upvmn7$1cnmp$1@dont-email.me> |
| In reply to | #381951 |
On 07/02/2024 08:42, David Brown wrote: > On 07/02/2024 03:57, vallor wrote: >> On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal) >> wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>: >> >>> bart <bc@freeuk.com> writes: >>>> On 04/02/2024 17:48, David Brown wrote: >>>>> On 03/02/2024 20:35, bart wrote: >>>> >>>>>> It is Windows that places more store by file extensions, which Linux >>>>>> people say is a bad thing. >>>>>> >>>>> >>>>> Windows is too dependent on them, and too trusting. >>>> >>>>>> But above you say that is the advantage of Linux. >>>>> >>>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect. >>>> >>>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker >>> >>> I've never seen a '.x ' suffix. Ever. And I use linker scripts >>> regularly. >> >> This was the first I'd heard about them in this context, but Open >> Network Computing's RPC (ONCRPC, was SunRPC) does use .x files >> for its RPC specifications. >> >> ONCRPC is a system for generating C stubs for network >> services, and it is (was?) also used to specify >> UNIX services like NFS and NIS. The Sun of yore >> were, indeed, good denizens of the Net. (So, crossposting >> conditions satisfied...I think?) >> >> Anyway, if you have the "standard" .x files >> installed on Linux Mint, they live in >> >> /usr/include/rpcsvc/ >> >> Also, there are linker scripts that end in ".x" >> which on my system live here: >> >> /usr/lib/x86_64-linux-gnu/ldscripts/ >> >> Fascinating to read -- and way over my head. (The >> man page for GNU ld says they are >> "AT&T's Link Editor Command Language syntax".) I'm >> not sure how often an average programmer would look >> around in there. >> >> In any event, the ".x" files in that directory are in >> the minority... >> > > If you look in that directory, you'll see all the files are ".x<flags>", > where <flags> are letters. So you get ".x", ".xbn", ".xc", ".xce", and > a dozen other combinations. I don't know the details of the flags, but > they generally refer to different arrangements of code and data (for > example, merging read-only data and executable code, or keeping them > separate). > > There's no doubt that ".x", and ".x<flags>", are common extensions for > linker files, but that they do not act as file extensions in the same > way as for other source code. Instead, they are sets of flags. (That's > why gcc treats any unknown extension as a linker file.) A bit like my tools treat an unknown extension as a file of whatever language the tool primarily works with? Cool. But is gcc primarily used for linker files? I'm not even sure what a linker file is!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-07 15:37 +0100 |
| Message-ID | <uq04im$1fb5h$1@dont-email.me> |
| In reply to | #381957 |
On 07/02/2024 11:40, bart wrote: > On 07/02/2024 08:42, David Brown wrote: >> On 07/02/2024 03:57, vallor wrote: >>> On Sun, 04 Feb 2024 20:55:12 GMT, scott@slp53.sl.home (Scott Lurndal) >>> wrote in <QQSvN.294647$Wp_8.94897@fx17.iad>: >>> >>>> bart <bc@freeuk.com> writes: >>>>> On 04/02/2024 17:48, David Brown wrote: >>>>>> On 03/02/2024 20:35, bart wrote: >>>>> >>>>>>> It is Windows that places more store by file extensions, which Linux >>>>>>> people say is a bad thing. >>>>>>> >>>>>> >>>>>> Windows is too dependent on them, and too trusting. >>>>> >>>>>>> But above you say that is the advantage of Linux. >>>>>> >>>>>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect. >>>>> >>>>> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker >>>> >>>> I've never seen a '.x ' suffix. Ever. And I use linker scripts >>>> regularly. >>> >>> This was the first I'd heard about them in this context, but Open >>> Network Computing's RPC (ONCRPC, was SunRPC) does use .x files >>> for its RPC specifications. >>> >>> ONCRPC is a system for generating C stubs for network >>> services, and it is (was?) also used to specify >>> UNIX services like NFS and NIS. The Sun of yore >>> were, indeed, good denizens of the Net. (So, crossposting >>> conditions satisfied...I think?) >>> >>> Anyway, if you have the "standard" .x files >>> installed on Linux Mint, they live in >>> >>> /usr/include/rpcsvc/ >>> >>> Also, there are linker scripts that end in ".x" >>> which on my system live here: >>> >>> /usr/lib/x86_64-linux-gnu/ldscripts/ >>> >>> Fascinating to read -- and way over my head. (The >>> man page for GNU ld says they are >>> "AT&T's Link Editor Command Language syntax".) I'm >>> not sure how often an average programmer would look >>> around in there. >>> >>> In any event, the ".x" files in that directory are in >>> the minority... >>> >> >> If you look in that directory, you'll see all the files are >> ".x<flags>", where <flags> are letters. So you get ".x", ".xbn", >> ".xc", ".xce", and a dozen other combinations. I don't know the >> details of the flags, but they generally refer to different >> arrangements of code and data (for example, merging read-only data and >> executable code, or keeping them separate). >> >> There's no doubt that ".x", and ".x<flags>", are common extensions for >> linker files, but that they do not act as file extensions in the same >> way as for other source code. Instead, they are sets of flags. >> (That's why gcc treats any unknown extension as a linker file.) > > A bit like my tools treat an unknown extension as a file of whatever > language the tool primarily works with? > > Cool. But is gcc primarily used for linker files? I'm not even sure what > a linker file is! > gcc (the program, as distinct from GCC the project) is a front-end - a "driver". It passes its input files and flags on to the configured tools, adding to or changing flags as appropriate, to run the C compiler, C pre-processor, assembler, C++ compiler, other compilers (Fortran, Ada, etc.), the linker, and so on. (The assembler and linker are not part of the GCC project, but any given gcc build will usually be configured to use an appropriate assembler and linker.) Use of specific linker files is not common for building code on PC's - the standard linker setups are usually fine. But it is quite common in embedded development and other most specialised builds. Then you pass one or more linker files to the linker, generally via the gcc front-end.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-04 22:51 +0100 |
| Message-ID | <upp0t1$3rjim$1@dont-email.me> |
| In reply to | #381757 |
On 04/02/2024 21:18, bart wrote:
> On 04/02/2024 17:48, David Brown wrote:
>> On 03/02/2024 20:35, bart wrote:
>
>>> It is Windows that places more store by file extensions, which Linux
>>> people say is a bad thing.
>>>
>>
>> Windows is too dependent on them, and too trusting.
>
>>> But above you say that is the advantage of Linux.
>>
>> Yes, it's a hands-down win for Linux (and other *nix) in this aspect.
>
> Yet it is Linux (manifested via gcc) where it ASSUMES .x is a linker
> script, and ASSUMES that .s is an assembly source file; INCORRECT
> assumptions.
>
No, they are almost always /correct/ assumptions. If you want to use .s
for a C file, that is allowed - but it is so unusual that you have to
tell gcc about it ("gcc -x c cfile.s" will work).
Would you prefer a system where the compiler just guesses and makes up
the rules as it goes along? (Here's a hint - a file can be valid C and
also valid C++, but compiling it in the different languages will give
different results.)
What works for little hobby tools does not always work at scale for
serious tools.
> I think I'm starting to understand the rules: whatever Windows does is
> always wrong, and whatever Linux does is always right!
>
You've claimed that many times over the years. If you were to stop
merely /starting/ to think that, and take it as the basic assumption,
then you would not always be correct - but you'd be wrong at lot less often!
> To be clear, this is the behaviour of /my/ applications, which work the
> same way on Windows /or/ Linux, that work primarily work on one type of
> file, that assume that file type no matter what the extension.
>
Exactly. For your little program that can't deal with more than one
type of file, you can do this. And since it is for your own little tool
that no one else uses, you can do it exactly as you like.
> BOTH methods can be problematic if you deliberately or accidentally mix
> up file types and extensions.
So stop deliberately being a screw-up. You'll find life vastly easier.
Accidents can happen on occasion, but you're a lot less likely to shoot
yourself in the foot if you stop aiming at your foot and squeezing the
trigger.
>
>>> And that's only when I run it under Linux. That's because under
>>> Linux, 'filename' and 'filename.' are distinct files; the "." is part
>>> of the file name, not a notional separator.
>>>
>>
>> Of course it is. It's simple and consistent.
>>
>> In Windows, it is sometimes part of a file name (when it is not the
>> last period in the name), sometimes a magical character that appears
>> or disappears (when the file ends in a period), and sometimes it
>> delimits a file extension.
>
> It probably still needs to be a notional dot for backwards compatibility
> over decades.
>
> The first two DEC systems I used had 6.3 filenames, storing 'sixbit'
> characters in 1.5 words for 36 bits, or using 'radix-50' in 3 words for
> 16 bits. You can see there is nowhere to put the dot.
>
> That was carried over to DOS's 8.3 filename.
At a time when real OS's had moved beyond that. What a stupid decision
- it's what you expect when you remember that MS DOS was written as a
quick hack on a system called "quick and dirty OS" as a way for MS to
con its customers.
>
> This dot then was really a virtual separator that did not need storing,
> any more than you need to store the dot in the ieee754 representation of
> 73.945.
>
> It has given very little trouble, and has the huge advantage that you
> can have default extensions on input files with no ambiguity.
>
> Let me guess: Unix allows you to have numbers like 73.945.112, while 73.
> is a different value from 73? Cool.
>
Um, you remember this is comp.lang.c ? "73" is an integer constant,
"73." is a double.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-04 23:11 +0000 |
| Message-ID | <upp5j8$3stas$1@dont-email.me> |
| In reply to | #381760 |
On 04/02/2024 21:51, David Brown wrote:
> On 04/02/2024 21:18, bart wrote:
>> BOTH methods can be problematic if you deliberately or accidentally
>> mix up file types and extensions.
>
> So stop deliberately being a screw-up.
I was replying initially to somebody claiming that being able to do:
cc prog.a
cc prog.b
cc prog.c
and marshalling the file into the right tool was not only some great
achievement only possible on Linux, but also desirable.
I think using dedicated tools instead is a better idea.
>
>> That was carried over to DOS's 8.3 filename.
>
> At a time when real OS's had moved beyond that.
When was that? The IBM PC came out in 1981. The DEC machines I mentioned
were still in use. Oh, you mean Unix was the One and Only Real OS? I get it.
What a stupid decision
> - it's what you expect when you remember that MS DOS was written as a
> quick hack on a system called "quick and dirty OS" as a way for MS to
> con its customers.
Funny you should fixate on that, and not on the idea of a business
computer running on a 4.8MHz 8088 processor with a crappy 'CGA' video
board design that would barely pass as a student assignment. (Oh, that
was IBM and not MS, and it is only MS you want to shit all over.)
However it brought business computing to the masses. Where were the
machines running your beloved Unix?
I believe you were working on Spectrums then or some such machines; what
filenames did /they/ allow, or did they not actually have a file system?
You're being unjust on the people working on all this stuff at that
period, trying to make things work with small processors, tiny amounts
of memory and limited storage.
>>
>> This dot then was really a virtual separator that did not need
>> storing, any more than you need to store the dot in the ieee754
>> representation of 73.945.
>>
>> It has given very little trouble, and has the huge advantage that you
>> can have default extensions on input files with no ambiguity.
>>
>> Let me guess: Unix allows you to have numbers like 73.945.112, while
>> 73. is a different value from 73? Cool.
>>
>
> Um, you remember this is comp.lang.c ? "73" is an integer constant,
> "73." is a double.
Yes. But the question is whether the "." separating out the two parts of
a filename should be actually stored, as a '.' character taking up extra
space.
It made perfect sense not to store it the time. But Unix made a decision
at the time to store it literally, which could also have been thought crass.
In hindsight, with filenames now allowing arbitrary dots, they made the
right decision. But that was more due to luck. And probably not having
to make concessions to running on low-end hardware.
You however would try and argue that some great foresight was
deliberately exercised and that the people behind those other systems
made a dumb decision.
I'm sorry but you weren't there.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-05 13:42 +0100 |
| Message-ID | <upql3h$9ooi$1@dont-email.me> |
| In reply to | #381769 |
On 05/02/2024 00:11, bart wrote: > On 04/02/2024 21:51, David Brown wrote: >> On 04/02/2024 21:18, bart wrote: > >>> BOTH methods can be problematic if you deliberately or accidentally >>> mix up file types and extensions. >> >> So stop deliberately being a screw-up. > > >>> That was carried over to DOS's 8.3 filename. >> >> At a time when real OS's had moved beyond that. > > When was that? The IBM PC came out in 1981. The DEC machines I mentioned > were still in use. Oh, you mean Unix was the One and Only Real OS? I get > it. > There have been lots of OS's. MS DOS was - from the beginning - a hack on a simple limited OS. Older systems, or systems for more limited hardware, had limits on their filenames - that is reasonable and makes sense. By the time of the IBM PC, that should not have been necessary - at least not /so/ short names. The all-caps names (which then led to the silly case insensitive behaviour) had no excuse at all. And /relying/ on file extensions for critical things like executable type was never smart. (File extensions for user convenience is fine as a useful convention.) > What a stupid decision >> - it's what you expect when you remember that MS DOS was written as a >> quick hack on a system called "quick and dirty OS" as a way for MS to >> con its customers. > > Funny you should fixate on that, and not on the idea of a business > computer running on a 4.8MHz 8088 processor with a crappy 'CGA' video > board design that would barely pass as a student assignment. (Oh, that > was IBM and not MS, and it is only MS you want to shit all over.) Is it "funny" that in discussion about operating systems, I talked about the operating system - not the hardware? I agree that the IBM PC hardware was pathetic for its time - for a start, it should have been, as the designers wanted, built around an 68000 cpu. > > However it brought business computing to the masses. Where were the > machines running your beloved Unix? They were doing all the important work. They still are. (And I certainly don't think Unix - either of that time, nor modern descendants, are perfect. But you only see everything as black or white, which is quite sad and pathetic.) > > I believe you were working on Spectrums then or some such machines; what > filenames did /they/ allow, or did they not actually have a file system? > There was some file system on microdrives - otherwise, no, no file system. I also worked with BBC Micros - now there was an OS that was extremely well designed. > You're being unjust on the people working on all this stuff at that > period, trying to make things work with small processors, tiny amounts > of memory and limited storage. > No, I just think they could have done a lot better with what they had. > >>> >>> This dot then was really a virtual separator that did not need >>> storing, any more than you need to store the dot in the ieee754 >>> representation of 73.945. >>> >>> It has given very little trouble, and has the huge advantage that you >>> can have default extensions on input files with no ambiguity. >>> >>> Let me guess: Unix allows you to have numbers like 73.945.112, while >>> 73. is a different value from 73? Cool. >>> >> >> Um, you remember this is comp.lang.c ? "73" is an integer constant, >> "73." is a double. > > > Yes. But the question is whether the "." separating out the two parts of > a filename should be actually stored, as a '.' character taking up extra > space. I understand how DOS and its descendants handle this. I understand how almost every other file system and OS handles this. I know which is better. > > It made perfect sense not to store it the time. But Unix made a decision > at the time to store it literally, which could also have been thought > crass. > > In hindsight, with filenames now allowing arbitrary dots, they made the > right decision. But that was more due to luck. And probably not having > to make concessions to running on low-end hardware. > > You however would try and argue that some great foresight was > deliberately exercised and that the people behind those other systems > made a dumb decision. > > I'm sorry but you weren't there. > I appreciate that many decisions were the best choice at the time, and afterwards you are stuck with the consequences of that. Most of what I think is bad in C falls into that category. But some decisions were also clearly inferior at the time they were made.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-05 14:59 +0100 |
| Message-ID | <upqpko$aild$1@dont-email.me> |
| In reply to | #381808 |
On 05.02.2024 13:42, David Brown wrote: > On 05/02/2024 00:11, bart wrote: >> >> [...] Oh, you mean Unix was the One and Only Real OS? I get it. (Obviously not.) > There have been lots of OS's. MS DOS was - from the beginning - a hack > on a simple limited OS. And MS marketing was able to foster a community who could easily be brainwashed to find it natural that SW is so buggy and unreliable. And few (from the many) flaws, deficiencies, and bugs can be clumsily worked around. Countless "experts" were arising from that who have specialized "guru wisdom" about the magic to work around some of these well known flaws. Blue screens were common. A standard tip - and even still in use nowadays! - was and is "Reboot your system.", and if that doesn't help then "Reinstall the software.", or the "Reinstall the OS" if nothing helped, and finally "Wait for version N+1 of this OS, there will be all good then." - and of course it never was. > > [...] > The all-caps names (which then led to the silly case insensitive > behaviour) had no excuse at all. All caps was initially a historic restriction of many OSes due to the limited character sets. At some point working case sensitivity became possible and supported; MS was not amongst the first here. Later the need for non-ASCII and internationalization became prevalent and it became technically possible to support that. Meanwhile we have multi- lingual computing. For certain user front-ends of applications it is more useful to not distinguish case; see Google search for a prominent example. For other application (or OS) interfaces it is necessary (or at least much desired) to support not only case sensitivity but also regular expression searches. Unix systems supported that inherently. In other contexts it needed decades to even consider supporting a switch to activate such a feature. Later applications supported own methods, for example to include or exclude words in searches. > And /relying/ on file extensions for > critical things like executable type was never smart. (File extensions > for user convenience is fine as a useful convention.) > >> [...] > > Is it "funny" that in discussion about operating systems, I talked about > the operating system - not the hardware? I agree that the IBM PC > hardware was pathetic for its time - for a start, it should have been, > as the designers wanted, built around an 68000 cpu. One of the best and outstanding pieces of hardware from that time was (IMO) the IBM PC's "Model M" keyboard. (I'm still typing on a Model M clone.) > >> You're being unjust on the people working on all this stuff at that >> period, trying to make things work with small processors, tiny amounts >> of memory and limited storage. (And I heard at that time that 640k would be more than enough. LOL.) > No, I just think they could have done a lot better with what they had. Indeed. (But they refused. It's easier to manipulate a user base by the marketing division than fix inherently broken things.) >>>> >>>> Let me guess: Unix allows you to have numbers like 73.945.112, while >>>> 73. is a different value from 73? Cool. Again "guessing"? Or just making up things? Or creating a straw man?" Frankly, I don't understand what argument you want to construct here, Bart. 73.945.112 seems obviously to be a standard representation of a number with eight figures, using one of many internationally used separators. While some computer languages indeed allow to process "73 945 112" and also "73945112", you cannot expect that legibility support. Mostly, if at all, you may have the option to choose decimals after the "comma" only, as in 123.34$ or 123,45€. (But your intention here was most likely anyway just a red herring.) >>> >>> Um, you remember this is comp.lang.c ? "73" is an integer constant, >>> "73." is a double. >> >> >> Yes. But the question is whether the "." separating out the two parts >> of a filename should be actually stored, as a '.' character taking up >> extra space. Filenames consisting of "two parts" is a fundamental misconception. > > I understand how DOS and its descendants handle this. I understand how > almost every other file system and OS handles this. I know which is > better. > >> [...] >> >> In hindsight, with filenames now allowing arbitrary dots, they made >> the right decision. (What a bright enlightenment. Great.) >> But that was more due to luck. And probably not >> having to make concessions to running on low-end hardware. (And again some stupid continuation; random guesses based on opinion.) >> [...] Janis
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-05 15:45 +0000 |
| Message-ID | <upqvq2$bnji$1@dont-email.me> |
| In reply to | #381810 |
On 05/02/2024 13:59, Janis Papanagnou wrote:
> On 05.02.2024 13:42, David Brown wrote:
>> On 05/02/2024 00:11, bart wrote:
>>>
>>> [...] Oh, you mean Unix was the One and Only Real OS? I get it.
>
> (Obviously not.)
>
>> There have been lots of OS's. MS DOS was - from the beginning - a hack
>> on a simple limited OS.
>
> And MS marketing was able to foster a community who could easily be
> brainwashed to find it natural that SW is so buggy and unreliable.
> And few (from the many) flaws, deficiencies, and bugs can be clumsily
> worked around. Countless "experts" were arising from that who have
> specialized "guru wisdom" about the magic to work around some of these
> well known flaws. Blue screens were common. A standard tip - and even
> still in use nowadays! - was and is "Reboot your system.", and if that
> doesn't help then "Reinstall the software.", or the "Reinstall the OS"
> if nothing helped, and finally "Wait for version N+1 of this OS, there
> will be all good then." - and of course it never was.
Yeah, because no other OS has ever required a hard reboot. I've had to
do a hard power-off and power-on cycle endless times on smart TVs,
phones and tablets. None of them ran Windows.
>>
>> [...]
>> The all-caps names (which then led to the silly case insensitive
>> behaviour) had no excuse at all.
>
> All caps was initially a historic restriction of many OSes due to the
> limited character sets. At some point working case sensitivity became
> possible and supported; MS was not amongst the first here. Later the
> need for non-ASCII and internationalization became prevalent and it
> became technically possible to support that. Meanwhile we have multi-
> lingual computing. For certain user front-ends of applications it is
> more useful to not distinguish case; see Google search for a prominent
> example.
Pretty much every front-end not aimed at technical users is
case-insensitive.
Most people will also come across case-sensitive filenames simply
because the underlying *nix file system is exposed.
Even then, sensible steps have been taken to ensure that main parts of
URLs and email addresses are case-insensitive. There it is easy to see
what chaos could ensue otherwise.
> Filenames consisting of "two parts" is a fundamental misconception.
File specs can consist of multiple parts. On OSes that used drive
letters like:
A:filename.ext
then that has 3 parts. It would be ludicrous to store that "A:" inside a
directory. Especiall on media that then ends up as drive B:.
Even in a file-spec like this:
/a/b/c/filename.ext
Is the full string "/a/b/c/filename.ext" stored in the directory entry
for this file, or is it split up into different components?
I don't know; you tell me. The former looks unwieldy.
On some OSes the filetype was an attribute, stored separately from the
filename, and displayed with a "." separator.
In the same way, with these qualified names in some language source code:
a.b.c
a::b::c
it is extremely unlikely that those "." and "::" symbols actually form
part of the identifier for each.
Meanwhile I need to use a small library of routines to split filespecs
up into path, base file, and extension.
>>
>> I understand how DOS and its descendants handle this. I understand how
>> almost every other file system and OS handles this. I know which is
>> better.
>>
>>> [...]
>>>
>>> In hindsight, with filenames now allowing arbitrary dots, they made
>>> the right decision.
>
> (What a bright enlightenment. Great.)
>
>>> But that was more due to luck. And probably not
>>> having to make concessions to running on low-end hardware.
>
> (And again some stupid continuation; random guesses based on opinion.)
But it might well be perfectly true; you don't know either. So it is
plausible.
Based on my examples above, having notional "." and "/" symbols seemed
the sensible thing to do. It is quite possible that Unix (remember this
was part of the same group that made all those wise decisions about C),
really did make that crass decision to actually store dots as part of
the filename.
BTW on Unix-like file systems, is a filename like "abc.def.ghi"
considered to have the extension "def.ghi", or "ghi"? If the latter,
then I take it that extensions can't have embedded dots?
On Windows, the extension is "ghi". If that is the case on Linux too,
then that treats the right-most dot specially.
But I get it: you deeply despise Windows, MSDOS, MS, and you hate me for
being an upstart.
>>> [...]
>
> Janis
>
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-05 11:25 -0800 |
| Message-ID | <uprcns$dspb$4@dont-email.me> |
| In reply to | #381821 |
On 2/5/2024 7:45 AM, bart wrote: [...] > Yeah, because no other OS has ever required a hard reboot. I've had to > do a hard power-off and power-on cycle endless times on smart TVs, > phones and tablets. None of them ran Windows. [...] You never experienced a blue screen of death on Windows?
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-05 22:46 +0000 |
| Message-ID | <uprof9$g01t$3@dont-email.me> |
| In reply to | #381821 |
On Mon, 5 Feb 2024 15:45:07 +0000, bart wrote: > Pretty much every front-end not aimed at technical users is > case-insensitive. Some Linux filesystems offer this option, should you want to enable it <https://lwn.net/Articles/784041/>.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-05 14:43 +0000 |
| Message-ID | <Gu6wN.397624$p%Mb.138214@fx15.iad> |
| In reply to | #381769 |
bart <bc@freeuk.com> writes: >On 04/02/2024 21:51, David Brown wrote: >> On 04/02/2024 21:18, bart wrote: > >>> BOTH methods can be problematic if you deliberately or accidentally >>> mix up file types and extensions. >> >> So stop deliberately being a screw-up. > >I was replying initially to somebody claiming that being able to do: > > cc prog.a > cc prog.b > cc prog.c > >and marshalling the file into the right tool was not only some great >achievement only possible on Linux, but also desirable. Nobody other than you have made such a claim.
[toc] | [prev] | [next] | [standalone]
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web