Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #171992 > unrolled thread
| Started by | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| First post | 2023-08-10 04:29 -0700 |
| Last post | 2023-09-13 09:40 -0700 |
| Articles | 19 on this page of 359 — 21 participants |
Back to article view | Back to comp.lang.c
bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:29 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 12:57 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 05:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-10 13:14 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 06:53 -0700
Re: bart again (UCX64) cross@spitfire.i.gajendra.net (Dan Cross) - 2023-08-16 11:52 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-16 02:31 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-28 11:43 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 03:47 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 18:43 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-10 04:59 -0700
Re: bart again (UCX64) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 17:45 +0300
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-28 19:19 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-29 22:01 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-29 20:00 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 00:25 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 01:35 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 11:38 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:06 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 15:53 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 12:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 22:59 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 15:54 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 00:17 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 16:30 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 11:58 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 05:32 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 14:45 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 07:43 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:56 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 08:38 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 12:56 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:09 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:12 +0200
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 23:53 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 14:39 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-31 20:56 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 14:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 15:30 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 16:17 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-08-31 19:36 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:26 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 13:17 -0700
Verbosity in command output (Was: bart again (UCX64)) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-31 21:43 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:31 +0000
Re: Verbosity in command output (Was: bart again (UCX64)) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-31 21:36 -0700
Re: Verbosity in command output (Was: bart again (UCX64)) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:07 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 15:32 -0700
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:05 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 22:07 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 23:18 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-08-31 23:03 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 16:46 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 01:44 +0100
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:09 -0700
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-31 18:11 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-31 18:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:38 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:40 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 01:29 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:28 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 12:01 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:20 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 13:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 13:39 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:29 +0200
Re: bart again (UCX64) Richard Harnden <richard.nospam@gmail.com> - 2023-09-01 14:32 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 18:14 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:01 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 14:53 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 15:57 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-01 19:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:55 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:27 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 20:46 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:29 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:19 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 13:56 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 16:05 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:17 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 10:34 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 03:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:43 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 04:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:16 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 18:33 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:33 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 15:27 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 17:18 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 16:26 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 19:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 19:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 20:48 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:25 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-04 21:56 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:34 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 21:06 +0100
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-04 13:09 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 16:04 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 00:52 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 17:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 15:33 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-05 14:55 +0000
Re: bart again (UCX64) Bobby Moore <bobbymoore018@gmail.com> - 2023-09-05 08:30 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 17:31 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 18:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 20:10 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 20:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 22:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:05 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:10 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 22:32 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:49 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 16:08 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 07:53 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 17:35 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 09:37 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 20:49 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-06 19:51 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-06 12:52 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:36 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:11 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 04:04 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:24 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 18:13 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-06 21:17 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 22:24 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 11:37 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 11:53 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 13:33 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:36 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 22:59 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-08 00:35 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:41 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 20:47 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 14:07 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 22:22 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 15:26 -0700
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-05 18:26 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-07 23:15 -0400
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 13:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 21:36 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-05 13:24 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:44 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 01:14 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 18:13 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:43 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:58 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 23:28 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-02 20:09 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 07:15 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 03:03 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:53 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:24 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 12:22 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 02:01 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 21:40 -0700
[OT] Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 17:06 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-03 18:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 10:39 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 07:33 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 16:26 +0100
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-02 09:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:22 +0100
Re: bart again (UCX64) vallor <vallor@cultnix.org> - 2023-09-05 01:38 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-04 20:05 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 16:45 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 06:49 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-05 05:30 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-05 17:16 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 08:47 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 19:57 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 19:01 -0700
Re: bart again (UCX64) James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-09-09 01:14 -0400
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 05:22 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 12:51 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 12:58 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 16:29 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 20:00 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 00:08 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 01:36 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:41 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 17:49 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:32 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:59 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:02 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 15:54 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 19:50 +0200
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-03 21:25 +0000
Re: bart again (UCX64) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-09-03 16:44 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:16 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:48 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 19:12 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 18:49 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 21:33 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 21:09 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 22:41 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:34 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 15:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 14:06 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:27 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 16:02 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 01:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 01:12 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:13 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 11:57 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 19:53 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:32 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:02 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 18:11 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:31 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 20:07 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 22:08 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:16 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 10:54 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:06 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 14:54 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 22:02 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:31 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 02:24 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 04:29 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 21:06 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 01:03 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 20:58 +0100
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 19:21 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 20:18 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 13:07 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 22:41 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 15:56 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:53 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 18:47 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:25 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-12 10:32 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 18:30 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 03:04 +0100
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 21:48 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:10 +0000
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 02:06 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 15:52 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:18 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 15:28 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 16:54 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 16:12 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:17 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:37 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:51 -0700
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 00:46 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:06 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:19 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 15:55 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 15:16 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:02 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:15 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:51 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:24 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:53 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:34 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:25 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:37 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:02 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:14 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:09 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:34 +0100
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:22 +0000
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:44 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 15:16 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 23:48 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 17:16 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:16 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:51 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:00 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:05 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:11 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:56 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:47 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:49 +0200
Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:27 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-10 12:06 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-08 05:03 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:39 +0100
Re: bart again (UCX64) candycanearter07 <no@thanks.net> - 2023-09-08 07:49 -0500
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:07 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:51 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:35 +0200
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:04 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:14 +0000
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:41 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-04 18:15 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 18:57 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 09:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-30 15:55 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 17:10 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 13:13 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:50 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:54 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 19:02 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-02 22:42 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 15:08 -0700
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:00 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 23:18 +0100
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 02:28 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 06:58 +0000
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 15:52 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 11:02 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:25 +0200
Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 16:49 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:16 +0200
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-02 18:11 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-02 22:08 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:48 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-02 14:52 -0700
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 02:23 -0700
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 03:47 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-03 18:44 +0000
Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 18:01 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-03 16:59 +0200
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-03 17:50 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 10:43 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 02:17 -0700
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:26 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 11:35 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 13:39 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 14:09 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 15:33 +0200
Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-01 05:14 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 17:41 +0000
Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-01 18:21 +0000
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-01 14:31 -0700
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-01 22:39 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-02 07:07 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:17 +0000
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 19:28 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 21:03 +0100
Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-01 11:23 +0200
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-31 20:50 +0100
Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-31 23:12 +0000
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-01 02:25 +0100
Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-31 20:37 -0700
Re: bart again (UCX64) Paul Edwards <mutazilah@gmail.com> - 2023-08-30 07:51 -0700
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 16:09 +0100
Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-08-30 20:17 +0100
Re: bart again (UCX64) Michael S <already5chosen@yahoo.com> - 2023-08-29 04:46 -0700
Buy Magic Mushrooms online Buy Magic Mushroom Chocolate Bars <taresa67kolyta@gmail.com> - 2023-09-13 09:40 -0700
Page 18 of 18 — ← Prev page 1 … 16 17 [18]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-09-01 05:14 -0700 |
| Message-ID | <8dda0711-2315-43b1-bc6e-8283b0afac55n@googlegroups.com> |
| In reply to | #173511 |
On Friday, 1 September 2023 at 11:36:09 UTC+1, Bart wrote: > > Everyone has been saying, do the build from inside the source directory. > They've also been saying don't put the object file in the source directory! > You don't want human-generated, human-readable, and therefore quite valuable files mixed with computer-generated intermediate files which are worthless except as intermediates, and usually only on that platform. But the normal answer is to create a "build" directory under the root of the source directory which you wrote yourself, or downloaded. Then all the compiler products and other cruft goes in there. You don't put anything of much value in the "build" directory, and if something goes badly wrong, often something to try is to delete it and start a clean rebuild. > > That means gcc breaks that rule by default. But look at this pattern: > > Object file written to: > > abc> gcc hello.c /abc/hello.o > abc> gcc /abc/hello.c /abc/hello.o > xyz> gcc /abc/hello.c /xyz/hello.o > > This looks wrong. > It's not too bad. You download whizzyproject ..................documents ..................source you make a new directory, build, under whizzyproject build> gcc ../source/*.c will create a.out in the build directory. > > If I give gcc 100 files to build, will it finish it in a few seconds, or > do I go and make a drink? Simply listing the same of each file will give > a useful indication of where it's up to and how until it's done. > Who knows. But it's not really a useful indication because C source files can vary wildly in length and complexity. The optimisation problem reduces to the halting problem, after all. However I agree that it;s nice to have a pacifier. Also, if the compiler crashes out or hangs whilst compiling barts_special_file.c, then it helps that its last message was "compiling barts_speciaL_file.c".
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 17:41 +0000 |
| Message-ID | <20230901102320.265@kylheku.com> |
| In reply to | #173511 |
On 2023-09-01, Bart <bc@freeuk.com> wrote:
> On 01/09/2023 09:43, David Brown wrote:
>> On 31/08/2023 21:26, Bart wrote:
>
>> Putting object files in the current directory is a useful default.
>
> 'gcc -c' will do that if the input file is in the same current directory.
>
> So if the current directory happens to be /abc, compiling hello.c will
> produce /abc/hello.o from /abc/hello.c.
You are right. I didn't even notice that or forgot about it all these
years. -c is only used in very trivial makefiles.
The built-in make recipe doesn't use it; it uses -o so that if you say,
obj/foo.o: src/foo.c
it works fine. According to the gcc man page, I would think that
-c turns src/foo.c into src/foo.o.
Quote
By default, the object file name for a source file is made by
replacing the suffix .c, .i, .s, etc., with .o.
That's literally saying src/foo.c becomes src/foo.o. If
src/foo.c becomes foo.o, then the way to describe it is:
By default, the object file name for a source file is made by
taking the base name of the source file, removing any directory path
components, and replacing the suffix .c, .i, .s, etc., with .o.
> Everyone has been saying, do the build from inside the source directory.
More generally, you do the build from a build directory. That is almost
tautological. If you're building there, it's a build directory.
It's okay for the build directory to be the source directory.
Many FOSS projects support both modes: you can build in the source
directory, or you can create a separate build directory and configure
from there and build from there.
(AutoConf projects are like this, ideally. Some maintainers don't test
building in a separate directory, and also do something clever which
breaks it. Downstream distro packagers then work around it somehow,
without submitting a fix upstream.)
> They've also been saying don't put the object file in the source directory!
David pointed out advantages in not doing that, even if the project is
being built from within its source tree (not in a separate
build directory). This is not some hard and fast rule, though.
> That means gcc breaks that rule by default. But look at this pattern:
> Object file written to:
>
> abc> gcc hello.c /abc/hello.o
> abc> gcc /abc/hello.c /abc/hello.o
> xyz> gcc /abc/hello.c /xyz/hello.o
>
> This looks wrong.
Yes; so people who write their own build script or use their own make
recipe for .c to .o instead of the built-in one, will soon discover that
it isn't doing what they want. They will stop relyin gon using -c
without -o, one way or another: fix their script, fix their custom build
recipe, or use the built-in one.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-09-01 18:21 +0000 |
| Message-ID | <VYpIM.195339$JG_b.57113@fx39.iad> |
| In reply to | #173534 |
Kaz Kylheku <864-117-4973@kylheku.com> writes: >On 2023-09-01, Bart <bc@freeuk.com> wrote: >> On 01/09/2023 09:43, David Brown wrote: >>> On 31/08/2023 21:26, Bart wrote: >David pointed out advantages in not doing that, even if the project is >being built from within its source tree (not in a separate >build directory). This is not some hard and fast rule, though. > >> That means gcc breaks that rule by default. But look at this pattern: > >> Object file written to: >> >> abc> gcc hello.c /abc/hello.o >> abc> gcc /abc/hello.c /abc/hello.o >> xyz> gcc /abc/hello.c /xyz/hello.o >> >> This looks wrong. > >Yes; so people who write their own build script or use their own make >recipe for .c to .o instead of the built-in one, will soon discover that >it isn't doing what they want. They will stop relyin gon using -c >without -o, one way or another: fix their script, fix their custom build >recipe, or use the built-in one. As a note, early C compilers did not support mixing -o and -c. That capability came later.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-09-01 14:31 -0700 |
| Message-ID | <87msy57f75.fsf@nosuchdomain.example.com> |
| In reply to | #173534 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
> On 2023-09-01, Bart <bc@freeuk.com> wrote:
>> On 01/09/2023 09:43, David Brown wrote:
>>> On 31/08/2023 21:26, Bart wrote:
>>
>>> Putting object files in the current directory is a useful default.
>>
>> 'gcc -c' will do that if the input file is in the same current directory.
>>
>> So if the current directory happens to be /abc, compiling hello.c will
>> produce /abc/hello.o from /abc/hello.c.
>
> You are right. I didn't even notice that or forgot about it all these
> years. -c is only used in very trivial makefiles.
>
> The built-in make recipe doesn't use it; it uses -o so that if you say,
>
> obj/foo.o: src/foo.c
>
> it works fine.
> According to the gcc man page, I would think that
> -c turns src/foo.c into src/foo.o.
Yes, and it works by invoking gcc with the "-c" option, which make knows
how to do.
For GNU make, `make -p` dumps the data base of rules and variable
values. On my system, part of the output is:
COMPILE.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c
Ignoring directory issues, if you want to generate an object file foo.o
from a C source file foo.c, you can use `gcc foo.c -c` or `gcc -c foo.c`
-- or, if you want to be explicit, `gcc foo.c -c -o foo.o`.
If you do `gcc foo.c -o foo.o`, the lack of a `-c` option tells it to
invoke the linker. It will create an executable, not an object file,
named "foo.o". That's very probably not what you want.
> Quote
>
> By default, the object file name for a source file is made by
> replacing the suffix .c, .i, .s, etc., with .o.
I agree that's potentially misleading. I think the intent was that
"object file name" is intended to refer just to the file *name*, not the
full file *path*.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-01 22:39 +0000 |
| Message-ID | <20230901153513.138@kylheku.com> |
| In reply to | #173584 |
On 2023-09-01, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> By default, the object file name for a source file is made by
>> replacing the suffix .c, .i, .s, etc., with .o.
>
> I agree that's potentially misleading. I think the intent was that
> "object file name" is intended to refer just to the file *name*, not the
> full file *path*.
Ah, but I have a piece of trivia for you:
_GNU Coding Standards_, July 1, 2021:
Please do not use the term “pathname” that is used in Unix
documentation; use “file name” (two words) instead. We use the term
“path” only for search paths, which are lists of directory names.
GNU programs and documentation are supposed to use file name
to refer to a path with multiple components too, not just one
component.
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-09-02 07:07 +0000 |
| Message-ID | <20230902000542.149@kylheku.com> |
| In reply to | #173592 |
On 2023-09-01, Kaz Kylheku <864-117-4973@kylheku.com> wrote: > On 2023-09-01, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>> By default, the object file name for a source file is made by >>> replacing the suffix .c, .i, .s, etc., with .o. >> >> I agree that's potentially misleading. I think the intent was that >> "object file name" is intended to refer just to the file *name*, not the >> full file *path*. > > Ah, but I have a piece of trivia for you: > > _GNU Coding Standards_, July 1, 2021: > > Please do not use the term “pathname” that is used in Unix > documentation; use “file name” (two words) instead. We use the term > “path” only for search paths, which are lists of directory names. > > GNU programs and documentation are supposed to use file name > to refer to a path with multiple components too, not just one > component. In the same document, something closer to this overall debate: The GNU Project regards standards published by other organizations as suggestions, not orders. We consider those standards, but we do not “obey” them. In developing a GNU program, you should implement an outside standard’s specifications when that makes the GNU system better overall in an objective sense. When it doesn’t, you shouldn’t. In most cases, following published standards is convenient for users—it means that their programs or scripts will work more portably. For instance, GCC implements nearly all the features of Standard C as specified by that standard. C program developers would be unhappy if it did not. And GNU utilities mostly follow specifications of POSIX.2; shell script writers and users would be unhappy if our programs were incompatible. But we do not follow either of these specifications rigidly, and there are specific points on which we decided not to follow them, so as to make the GNU system better for users. For instance, Standard C says that nearly all extensions to C are prohibited. How silly! GCC implements many extensions, some of which were later adopted as part of the standard. If you want these constructs to give an error message as “required” by the standard, you must specify ‘--pedantic’, which was implemented only so that we can say “GCC is a 100% implementation of the standard”, not because there is any reason to actually use it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 19:17 +0000 |
| Message-ID | <20230831120802.994@kylheku.com> |
| In reply to | #173404 |
On 2023-08-31, Bart <bc@freeuk.com> wrote: > On 31/08/2023 13:36, David Brown wrote: >> So whatever your default here - whether it is generating the object file >> in the same directory as the source file, or generating it in the >> current directory - it will be convenient in some cases, and completely >> wrong in other cases. > > But putting it in the current directory is sloppy. The current location > can be arbitrary (or it might not be writeable): > > c:\random>gcc \proj1\foo.c > c:\random>gcc \proj2\bar.c > > Here, both compilations generate a.exe. But to cap that, both end up in > c:\random; the second overwrites the first, something you might be > unaware of. Nobody cares about this in the world of building components from C. The build systems by and large operate from the assumption that the current working directory is the top-level build directory. If you do $ make -f /path/to/project/build/Makefile it will not work. The correct ways, if you're not in that directory are any of these: $ cd /path/to/project/build; make or $ make -C /path/to/project/build or, if the name of the makefile is nonstandard: $ make -C /path/to/project/build -f Makefile.foo The argument to -f is considered from the directory that was changed into with -C. While you could probably make a Makefile that can be dispatched from anywhere without changing the current working directory, I suspect there is zero demand. If you end up feeding resolvd, absolute paths to your tools, that's actually a negative. The __FILE__ macro resolves to something that makes no ssense on the target system where the program is running like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just "src/parser.c". -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 19:28 +0000 |
| Message-ID | <20230831121856.53@kylheku.com> |
| In reply to | #173422 |
On 2023-08-31, Kaz Kylheku <864-117-4973@kylheku.com> wrote: > On 2023-08-31, Bart <bc@freeuk.com> wrote: >> On 31/08/2023 13:36, David Brown wrote: >>> So whatever your default here - whether it is generating the object file >>> in the same directory as the source file, or generating it in the >>> current directory - it will be convenient in some cases, and completely >>> wrong in other cases. >> >> But putting it in the current directory is sloppy. The current location >> can be arbitrary (or it might not be writeable): >> >> c:\random>gcc \proj1\foo.c >> c:\random>gcc \proj2\bar.c >> >> Here, both compilations generate a.exe. But to cap that, both end up in >> c:\random; the second overwrites the first, something you might be >> unaware of. > > Nobody cares about this in the world of building components from C. > > The build systems by and large operate from the assumption that > the current working directory is the top-level build directory. In fact, I should add, there is a practice of separating source and build directories. Any properly constructed AutoConf project supports this: $ mkdir build-dir $ cd build-dir build-dir $ /path/to/some/project/configure You create a build directory and call a configure script located elsewhere. It prepares that build directory for building the program. build-dir $ make The build references source files in /path/to/some/project. It drops object files here, inthis directory. Or some child like obj/ depending on the exact build system. You don't want to be dropping binaries in the sae place where the sources are located. *THAT* location may be read-only! Building sources that sit on a read-only mounted filesystem is a thing. The MIT XWindow system devised a scheme for dealing with this: the lndir utility. With lndir, you create a parallel tree to the target source tree, populated with symlinks: $ mkdir build-dir $ cd build-dir build-dir$ lndir /path/to/some/project . A directory structure skeleton is created mirroring that of the target projet, and populated with symlinks to each of its files. lndir's man page says: "This is usually useful for maintaining source code for different machine architectures. You create a shadow directory containing links to the real source, which you will have usually mounted from a remote machine." I was once employed producing a from-scratch embedded Linux distro, and doing kernel work, toolchain support and such. I religiously used separate build directories for everything I built. A few programs refused to cooperate. For those that couldn't be patched, I reached for lndir. The Linux kernel cannot (or couldn't at the time?) support separate build directories; I used lndir and it worked like a charm. That allowed me to build the same tree for x86 and MIPS without its cooperation. (The one thing that defeated lndir was that goddamed ASDF build system for Common Lisp. Internally, it called (truepath ...) which resolves all symlinks, and then it calculated object paths from the resolved source paths.) But anyway, if you're sitting in a different tree from where your source files are, you rarely want object files to be pooped into that tree, instead of this one here. If you do, you're an oddball, and nobody will listen to you; they will say, just change to that directory and work there. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 21:03 +0100 |
| Message-ID | <ucqrma$3e1l4$1@dont-email.me> |
| In reply to | #173424 |
On 31/08/2023 20:28, Kaz Kylheku wrote:
> On 2023-08-31, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
>> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>>> On 31/08/2023 13:36, David Brown wrote:
>>>> So whatever your default here - whether it is generating the object file
>>>> in the same directory as the source file, or generating it in the
>>>> current directory - it will be convenient in some cases, and completely
>>>> wrong in other cases.
>>>
>>> But putting it in the current directory is sloppy. The current location
>>> can be arbitrary (or it might not be writeable):
>>>
>>> c:\random>gcc \proj1\foo.c
>>> c:\random>gcc \proj2\bar.c
>>>
>>> Here, both compilations generate a.exe. But to cap that, both end up in
>>> c:\random; the second overwrites the first, something you might be
>>> unaware of.
>>
>> Nobody cares about this in the world of building components from C.
>>
>> The build systems by and large operate from the assumption that
>> the current working directory is the top-level build directory.
>
> In fact, I should add, there is a practice of separating source
> and build directories.
>
> Any properly constructed AutoConf project supports this:
>
> $ mkdir build-dir
> $ cd build-dir
> build-dir $ /path/to/some/project/configure
>
> You create a build directory and call a configure script located
> elsewhere. It prepares that build directory for building the program.
>
>
> build-dir $ make
>
> The build references source files in /path/to/some/project.
>
> It drops object files here, inthis directory. Or some child like obj/
> depending on the exact build system.
>
> You don't want to be dropping binaries in the sae place where the
> sources are located.
>
> *THAT* location may be read-only!
The location that you invoke the compiler from may be read-only!
For example, DVD-ROM drive, if you still have one.
> Building sources that sit on a read-only mounted filesystem is a thing.
I can build and run applications in my language on a read-only device
like this:
ms prog
This runs the app from source without creating an executable file.
>
> The MIT XWindow system devised a scheme for dealing with this: the lndir
> utility.
>
> With lndir, you create a parallel tree to the target source tree,
> populated with symlinks:
>
>
> $ mkdir build-dir
> $ cd build-dir
> build-dir$ lndir /path/to/some/project .
>
> A directory structure skeleton is created mirroring that of the
> target projet, and populated with symlinks to each of its files.
>
> lndir's man page says:
>
> "This is usually useful for maintaining source code for different
> machine architectures. You create a shadow directory containing links
> to the real source, which you will have usually mounted from a
> remote machine."
>
> I was once employed producing a from-scratch embedded Linux distro,
> and doing kernel work, toolchain support and such.
>
> I religiously used separate build directories for everything I built.
> A few programs refused to cooperate. For those that couldn't be patched,
> I reached for lndir.
>
> The Linux kernel cannot (or couldn't at the time?) support separate
> build directories; I used lndir and it worked like a charm. That allowed
> me to build the same tree for x86 and MIPS without its cooperation.
>
> (The one thing that defeated lndir was that goddamed ASDF build system
> for Common Lisp. Internally, it called (truepath ...) which resolves
> all symlinks, and then it calculated object paths from the resolved
> source paths.)
>
> But anyway, if you're sitting in a different tree from where your
> source files are, you rarely want object files to be pooped into
> that tree, instead of this one here.
And yet, when you do:
gcc hello.c
it will write a.out or a.exe in the same folder.
> If you do, you're an oddball, and nobody will listen to you;
> they will say, just change to that directory and work there.
I guess I'm an oddball. I routinely modify source files and write new
EXEs in the same folder. What's the point of mucking about with a
special folder just for the one EXE file?
For a user installation, then sure, but a user installation is something
removed from a developer's directory tree.
The impression I get is that in Linux, the entire file system is
considered to be one giant developer's tree, and installed software is
part of it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-09-01 11:23 +0200 |
| Message-ID | <ucsaj3$3nd9i$2@dont-email.me> |
| In reply to | #173429 |
On 31/08/2023 22:03, Bart wrote: > On 31/08/2023 20:28, Kaz Kylheku wrote: >> You don't want to be dropping binaries in the sae place where the >> sources are located. >> >> *THAT* location may be read-only! > > The location that you invoke the compiler from may be read-only! Yes - that is entirely true. That is why any choice of default here is only going to suit some use-cases. That is why gcc's choice is not perfect for everyone - just like /your/ choice is not perfect for everyone. Can you still not understand what people are trying to tell you? Are you so obsessed with screaming at everything that gcc and/or Linux does, and screaming at everyone who uses them, that this has still not sunk in? Defaults work in some cases, not others. > > I guess I'm an oddball. I routinely modify source files and write new > EXEs in the same folder. What's the point of mucking about with a > special folder just for the one EXE file? > You do realise that if you go to your source directory and use "gcc", the default is to put the output files in that same directory, just like if you use "bcc" ? So gcc's defaults work perfectly well for compiling the way you want - all you need is to give a name for the exe file that suits your preferences (it gets put in the directory you want).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-31 20:50 +0100 |
| Message-ID | <ucqqum$3du9m$1@dont-email.me> |
| In reply to | #173422 |
On 31/08/2023 20:17, Kaz Kylheku wrote:
> On 2023-08-31, Bart <bc@freeuk.com> wrote:
>> On 31/08/2023 13:36, David Brown wrote:
>>> So whatever your default here - whether it is generating the object file
>>> in the same directory as the source file, or generating it in the
>>> current directory - it will be convenient in some cases, and completely
>>> wrong in other cases.
>>
>> But putting it in the current directory is sloppy. The current location
>> can be arbitrary (or it might not be writeable):
>>
>> c:\random>gcc \proj1\foo.c
>> c:\random>gcc \proj2\bar.c
>>
>> Here, both compilations generate a.exe. But to cap that, both end up in
>> c:\random; the second overwrites the first, something you might be
>> unaware of.
>
> Nobody cares about this in the world of building components from C.
I guess that's because people using off-the-shelf tools are forced to do
things the way the tools dictate. They don't have a choice!
After a while they become inured enough to think that's the only way it
can be.
>
> The build systems by and large operate from the assumption that
> the current working directory is the top-level build directory.
So, you have to build things in-situ. To build multiple projects, you
have to navigate from folder to folder.
Whereas I can build all my language projects from one location, for example:
c:\demo>mm \ax\aa
Compiling \ax\aa.m------ to \ax\aa.exe
c:\demo>mm \cx\cc
Compiling \cx\cc.m------ to \cx\cc.exe
c:\demo>mm \qx\qq
Compiling \qx\qq.m------ to \qx\qq.exe
c:\demo>mm \mx\mm
Compiling \mx\mm.m------ to \mx\mm.exe
> If you do
>
> $ make -f /path/to/project/build/Makefile
>
> it will not work.
Why doesn't the tool just navigate to that path? And maybe, navigate
back to the start point when it's done?
Oh, I get it, 'zero demand'!
(You can see I don't use makefiles; most of them would consist of one line.)
The correct ways, if you're not in that
> directory are any of these:
>
> $ cd /path/to/project/build; make
>
> or
>
> $ make -C /path/to/project/build
>
> or, if the name of the makefile is nonstandard:
>
> $ make -C /path/to/project/build -f Makefile.foo
>
> The argument to -f is considered from the directory that
> was changed into with -C.
>
> While you could probably make a Makefile that can be dispatched from
> anywhere without changing the current working directory, I suspect there
> is zero demand.
I was right...
> If you end up feeding resolvd, absolute paths to your tools, that's
> actually a negative. The __FILE__ macro resolves to something that
> makes no ssense on the target system where the program is running
> like "/home/bob/open-source-projects/foo/src/parsere.c"instead of just
> "src/parser.c".
__FILE__ is a compile-time thing. But people do feed absolute or
sometimes relative paths to their compilers; the OP did so for example.
Also, that Baby X RC project was built with a command line like this:
gcc *.c abc\*.c def\*.c
Whatever path is provided for a source file, is what ends up as a a
prefix to __FILE__. You don't want a dozen files, all called foo.c but
in different folders, to all show "foo.c" in their __FILE__ macros; that
is not helpful!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <864-117-4973@kylheku.com> |
|---|---|
| Date | 2023-08-31 23:12 +0000 |
| Message-ID | <20230831155059.745@kylheku.com> |
| In reply to | #173426 |
On 2023-08-31, Bart <bc@freeuk.com> wrote: > On 31/08/2023 20:17, Kaz Kylheku wrote: >> On 2023-08-31, Bart <bc@freeuk.com> wrote: >>> On 31/08/2023 13:36, David Brown wrote: >>>> So whatever your default here - whether it is generating the object file >>>> in the same directory as the source file, or generating it in the >>>> current directory - it will be convenient in some cases, and completely >>>> wrong in other cases. >>> >>> But putting it in the current directory is sloppy. The current location >>> can be arbitrary (or it might not be writeable): >>> >>> c:\random>gcc \proj1\foo.c >>> c:\random>gcc \proj2\bar.c >>> >>> Here, both compilations generate a.exe. But to cap that, both end up in >>> c:\random; the second overwrites the first, something you might be >>> unaware of. >> >> Nobody cares about this in the world of building components from C. > > I guess that's because people using off-the-shelf tools are forced to do > things the way the tools dictate. They don't have a choice! That is false; the tools are quite flexible and will do things according to someone else's preferences. The tools won't do that by default; that would break them for everyone who relies on them to behave in their default way. > After a while they become inured enough to think that's the only way it > can be. > >> >> The build systems by and large operate from the assumption that >> the current working directory is the top-level build directory. > > So, you have to build things in-situ. No you don't; but it works well that way given how the system is designed. Why swim against the tidee if there is no benefit. > To build multiple projects, you > have to navigate from folder to folder. The biggest consumers of multipel projects are distros and distro maintainers. GNU/Linux (and other) distros are certainly not built by someone who manually navigates from folder to folder. The distro build does that. From the build person's point of view, that's one thing to run, in one place. > Whereas I can build all my language projects from one location, for example: > > c:\demo>mm \ax\aa > Compiling \ax\aa.m------ to \ax\aa.exe gcc does this for object files: gcc path/to/foo.c -c produces path/to/foo.o. The default executable is a.out, or else whatever you pass to -o is taken verbatim. It's common for .o files to be together with the .c files, but for the linked executable to be in the root directory of the project. However, the -c option isn't useful if we want to have separate build and source directories, or separate object directories for different architectures. The default build recipe does the trick; you just set up the dependencies correctly, e.g. objs/x86_64/parser/scanner.o: src/parser/scanner.c The recipe will compile src/parser/scanner.c and use -o objs/x86_64/parser/scanner.o . > c:\demo>mm \cx\cc > Compiling \cx\cc.m------ to \cx\cc.exe > > c:\demo>mm \qx\qq > Compiling \qx\qq.m------ to \qx\qq.exe > > c:\demo>mm \mx\mm > Compiling \mx\mm.m------ to \mx\mm.exe That's just your preference, it would be better to have cc.exe, qe.exe and mm.exe right here in this directory instead of being buried in subdirectories. There are Makefiles that bury things that way; they are irksome. Hey, make worked; where is the program??? Ah, in src/output, whatever for ... >> If you do >> >> $ make -f /path/to/project/build/Makefile >> >> it will not work. > > Why doesn't the tool just navigate to that path? Well, because it's a file, and not a directory. So the question is why doesn't it navigate to the path /path/to/project/build and then run Makefile? Because navigating to a directory is what the -C option does, and only that option. (If you don't like those conventions, you can write a mymake script which recognizes your preferred conventions and then generates an equivalent call to make.) > And maybe, navigate > back to the start point when it's done? That's not necessary; when a child process does chdir(), the parent is not affected. When you run a tool that changes directory, your current directory is not affected. I'm pretty sure Windows works that way too. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-09-01 02:25 +0100 |
| Message-ID | <ucreit$3g9id$1@dont-email.me> |
| In reply to | #173453 |
On 01/09/2023 00:12, Kaz Kylheku wrote: > On 2023-08-31, Bart <bc@freeuk.com> wrote: > The tools won't do that by default; that would break them for everyone > who relies on them to behave in their default way. That's tool1.exe >> Whereas I can build all my language projects from one location, for example: >> >> c:\demo>mm \ax\aa >> Compiling \ax\aa.m------ to \ax\aa.exe > > gcc does this for object files: > > gcc path/to/foo.c -c > > produces path/to/foo.o. Not on my machine. This is why I raised the issue. Using gcc -c, the .o file is always placed in the "." path, irrespective of the path prepended to the input filename. That's how it behaves on Windows and under WSL. >> c:\demo>mm \cx\cc >> Compiling \cx\cc.m------ to \cx\cc.exe >> >> c:\demo>mm \qx\qq >> Compiling \qx\qq.m------ to \qx\qq.exe >> >> c:\demo>mm \mx\mm >> Compiling \mx\mm.m------ to \mx\mm.exe > > That's just your preference, it would be better to have cc.exe, qe.exe > and mm.exe right here in this directory instead of being buried in > subdirectories. (My normal process is to build within the development directory, and use a script to move a production executable to where it normally lives. The behaviour that you describe could result in multiple mm.exe files in assorted locations, which is undesirable. Because I mostly work on compilers, I may be testing this new compiler on one within a different set of folders. I don't want the executables from that one to contaminate any here, even if they have different names.) > There are Makefiles that bury things that way; they are irksome. > Hey, make worked; where is the program??? Ah, in src/output, > whatever for ... Oh, if only there was a way for the compiler to just tell you where it's going to put the output! >> And maybe, navigate >> back to the start point when it's done? > > That's not necessary; It might be if you decided to run the command again. But with a different start location, who knows what might happen? when a child process does chdir(), the parent > is not affected. When you run a tool that changes directory, your > current directory is not affected. > > I'm pretty sure Windows works that way too. I find it hard to change the CWD programmatically, at least persistently. But these are scripts where you can issue actual CD commands.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-31 20:37 -0700 |
| Message-ID | <87r0ni7edg.fsf@nosuchdomain.example.com> |
| In reply to | #173453 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> gcc does this for object files:
>
> gcc path/to/foo.c -c
>
> produces path/to/foo.o.
>
> The default executable is a.out, or else whatever you pass to -o
> is taken verbatim.
Can you double check that? Here's what I get on my system
(Ubuntu 22.04.3, gcc 11.4.0).
$ find . -type f
./path/to/foo.c
$ gcc path/to/foo.c -c
$ find . -type f
./path/to/foo.c
./foo.o
$
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Paul Edwards <mutazilah@gmail.com> |
|---|---|
| Date | 2023-08-30 07:51 -0700 |
| Message-ID | <90966998-2e2a-4462-88b1-3c7dd6a05b34n@googlegroups.com> |
| In reply to | #173265 |
On Wednesday, August 30, 2023 at 6:38:30 PM UTC+8, Bart wrote:
> I can't guarantee anything, but sometimes I will try and fix something I
> find irksome, just for my own satisfaction.
Ok, but it is cc64 that I need (the thing you released to
the public domain), and that is generated code, and you
can no longer generate it, and it's nominally not
maintainable.
> than F()), I know about. The increment one is new. However, I can't
> reproduce it. This program:
I confirmed the problem is still occurring.
> rec x = {999, NULL};
> rec* p = &x;
>
> x.fbuf = &a[2];
>
> printf("*p->fbuf = %d\n", *p->fbuf);
>
> *p->fbuf++ = 77; // From your example
I am doing a function call. It's not a simple struct.
I also don't know whether you are using the same
cc64 that I am.
> gives the same results with both bcc and gcc, whatever T is chosen. What
> is the actual type of fbuf? And at what offset is it within __stdin? I
> tried with and without that dummy field.
char * and 32.
C:\devel\pdos\pdpclib>grep fbuf stdio.h | grep char
stdio.h: char *fbuf; /* file buffer - this is what all the routines
C:\devel\pdos\pdpclib>git diff .
diff --git a/pdpclib/pdptest.c b/pdpclib/pdptest.c
index b877649e..348b587b 100644
--- a/pdpclib/pdptest.c
+++ b/pdpclib/pdptest.c
@@ -14,6 +14,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <stddef.h>
static char buf[6144]; /* arbitrary buffer size */
@@ -37,6 +38,7 @@ int main(int argc, char **argv)
#endif
printf("welcome to pdptest\n");
+ printf("%d\n", offsetof(FILE, fbuf));
#ifndef SEGHACK
#if defined(__SUBC__) && defined(__64BIT__)
C:\devel\pdos\pdpclib>pdptest
welcome to pdptest
32
main function is at 00409020
allocating 10 bytes
m1 is 0009AA48
allocating 20 bytes
m2 is 000920D8
stack is around 0061FDD8
usage: pdptest [-bb/-tt/-tb/-bt] <infile> <outfile>
default is text to text copy
C:\devel\pdos\pdpclib>
__PDPCLIB_HEADFUNC FILE **__gtin(void);
#define __stdin (*(__gtin()))
Relevant code is here:
https://sourceforge.net/p/pdos/gitcode/ci/master/tree/pdpclib/
And to reproduce the problem do this:
C:\devel\pdos\pdpclib>git diff .
diff --git a/pdpclib/start.c b/pdpclib/start.c
index a2662643..e5a6c412 100644
--- a/pdpclib/start.c
+++ b/pdpclib/start.c
@@ -523,7 +523,7 @@ __PDPCLIB_API__ int CTYP __start(char *p)
__stdin->bufTech = _IOLBF;
__stdin->intBuffer = buffer1;
__stdin->fbuf = __stdin->intBuffer + 2;
-#ifdef __CC64__
+#ifdef __XCC64__
*__stdin->fbuf = '\0';
__stdin->fbuf++;
*__stdin->fbuf = '\0';
C:\devel\pdos\pdpclib>
C:\devel\pdos\pdpclib>pdmake -f makefile.c64
C:\devel\pdos\pdpclib>pdptest
C:\devel\pdos\pdpclib>
(crashes without displaying anything)
But reproducing it requires the supporting utilities from
PDOS/386 plus:
C:\devel\pdos\src>pdmake -f makek32.s64
before running the above, in order to produce kernel32.lib.
You might be able to get kernel32.lib from elsewhere.
Also during development I discovered some problems with
pdld and those are only in the source tree, not the PDOS
disk, but I don't think they are required for the above (and
that is why I didn't mention makek32.n64).
BFN. Paul.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-30 16:09 +0100 |
| Message-ID | <ucnm3l$2pdjd$1@dont-email.me> |
| In reply to | #173303 |
On 30/08/2023 15:51, Paul Edwards wrote:
> On Wednesday, August 30, 2023 at 6:38:30 PM UTC+8, Bart wrote:
>
>> I can't guarantee anything, but sometimes I will try and fix something I
>> find irksome, just for my own satisfaction.
>
> Ok, but it is cc64 that I need (the thing you released to
> the public domain), and that is generated code, and you
> can no longer generate it, and it's nominally not
> maintainable.
>
> > than F()), I know about. The increment one is new. However, I can't
>> reproduce it. This program:
>
> I confirmed the problem is still occurring.
>
>> rec x = {999, NULL};
>> rec* p = &x;
>>
>> x.fbuf = &a[2];
>>
>> printf("*p->fbuf = %d\n", *p->fbuf);
>>
>> *p->fbuf++ = 77; // From your example
>
> I am doing a function call. It's not a simple struct.
I missed that completely. I'll have to do a bigger test!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-30 20:17 +0100 |
| Message-ID | <uco4kl$2rp1d$1@dont-email.me> |
| In reply to | #173306 |
On 30/08/2023 16:09, Bart wrote:
> On 30/08/2023 15:51, Paul Edwards wrote:
>> On Wednesday, August 30, 2023 at 6:38:30 PM UTC+8, Bart wrote:
>>
>>> I can't guarantee anything, but sometimes I will try and fix something I
>>> find irksome, just for my own satisfaction.
>>
>> Ok, but it is cc64 that I need (the thing you released to
>> the public domain), and that is generated code, and you
>> can no longer generate it, and it's nominally not
>> maintainable.
>>
>> > than F()), I know about. The increment one is new. However, I can't
>>> reproduce it. This program:
>>
>> I confirmed the problem is still occurring.
>>
>>> rec x = {999, NULL};
>>> rec* p = &x;
>>>
>>> x.fbuf = &a[2];
>>>
>>> printf("*p->fbuf = %d\n", *p->fbuf);
>>>
>>> *p->fbuf++ = 77; // From your example
>>
>> I am doing a function call. It's not a simple struct.
>
> I missed that completely. I'll have to do a bigger test!
>
>
It took me nearly half an hour to sort out the right combinations of
"*", "." and "->" operations for this test.
BCC's code goes wrong here in this equivalent code:
*(*F())->fbuf++ = 77;
It's going to be too much effort to fix. I set up the same test in my
main non-C language, where it looks like this:
F().fbuf++^:=77
(Two of the three necessary derefs are applied automatically.)
Here it works OK. I think any future efforts in the BCC code generator,
if I ever get back to it, are better spent in porting the back end from
the other compiler.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-08-29 04:46 -0700 |
| Message-ID | <c0a55bc5-6cfd-4c76-90c1-aa208574b58bn@googlegroups.com> |
| In reply to | #171992 |
nothing
[toc] | [prev] | [next] | [standalone]
| From | Buy Magic Mushroom Chocolate Bars <taresa67kolyta@gmail.com> |
|---|---|
| Date | 2023-09-13 09:40 -0700 |
| Subject | Buy Magic Mushrooms online |
| Message-ID | <2c9aa176-b1a3-41d1-b9c6-83c00f3f024cn@googlegroups.com> |
| In reply to | #171992 |
Microdosing refers to the practice of regularly using small amounts of psychedelic substances that do not impair cognitive function. mushroom candy bars The researchers also found that older microdosers showed larger improvements in the psychomotor test, but not cognitive function, than non-microdosers. This effect was largely due to older participants over the age of 55 years using a combination of psilocybin, lion’s mane, and niacin.https://buymushroomschocolatebars.com/shop/ Buy cap up bar: https://buymushroomschocolatebars.com/product/cap-up-chocolate-bar/ Buy fusion bars :https://buymushroomschocolatebars.com/product/fusion-bar/ Buy Chocolate Chuckle Mushroom Chocolate Bar: https://buymushroomschocolatebars.com/product/chocolate-chuckle-mushroom-chocolate-bar/ Buy Winder Bar Mushroom Chocolate Bar :https://buymushroomschocolatebars.com/product/wodner-magic-mushroom-infused-chocolate-bars/ Buy Shroomies Microbites Assorted Gummies USA: https://buymushroomschocolatebars.com/product/shroomies-microbites-assorted-gummies-3000mg-2/ Buy Trippy Treats Mushrooms Chocolate Bars | Trippy Chocolate Bars: https://buymushroomschocolatebars.com/product/trippy-treats-mushroom-chocolate-bars/ Buy Psilo Gummies California| Psilocybin Mushroom Gummies https://buymushroomschocolatebars.com/product/psilo-psilocybin-mushroom-gummy-cubes-3-5g/ Magic Boom Bar | Buy Magic Mushroom Chocolate Bar https://buymushroomschocolatebars.com/product/magic-boom-bars-3500mg/ Buy Green Apple Mushroom Gummies: https://buymushroomschocolatebars.com/product/green-apple-mushroom-gummy-alice/ Buy Dark Chocolates: https://buymushroomschocolatebars.com/product/dark-chocolate-square-room-920/ Buy One Up Chocolate Bar | One Up Mushroom Bar For Sale https://buymushroomschocolatebars.com/product/3-5g-one-up-mushroom-chocolate-bars/ Buy Trippy Flipp Mushroom Chocolates: https://buymushroomschocolatebars.com/product/3-5g-trippy-flip-milk-mushroom-chocolate-bars/ Cherry Chocolate Gummies: https://buymushroomschocolatebars.com/product/cherry-mushroom-gummy-alice/ In recent years, there has been a resurgence of scientific and popular interest in the potential use of psychedelic drugs for the treatment of depression, anxiety, and post-traumatic stress. For instance, psilocybin, the active ingredient in magic mushrooms, has shown a tusted Source promise in the treatment of individuals with depression, anxiety, and substance use disorders. Naturally occurring psychedelic substances such as psilocybin extract from magic mushrooms and mescaline have been used for their beneficial health effects for thousands of years. The classification of psychedelic substances such as psilocybin and LSD as drugs of abuse without any medical use has, however, hindered research on the therapeutic effects of these substances.https://buymushroomschocolatebars.com/product/3-5g-trippy-flip-milk-mushroom-chocolate-bars/ These studies have generally used regular doses of psilocybin that produce euphoric and hallucinogenic effects. However, the use of regular doses of psilocybin can also produce unpleasant and terrifying experiences, also referred to as “bad trips” The researchers found that microdosers showed greater improvements in mood and larger reductions in symptoms of depression, anxiety, and stress over the study period than non-microdosers. These positive effects of microdosing were observed in all participants, regardless of whether they used psilocybin alone or a combination of either psilocybin with lion’s mane, or psilocybin, lion’s mane, and niacin. Moreover, microdosing psilocybin resulted in similar levels of improvements in mental health and mood across age groups, genders, and among individuals who did or did not have mental health concerns. The only exception was female microdosers who showed larger reductions in depressive symptoms than males. https://buymushroomschocolatebars.com/product/buy-honduras-mushroom-cubensis/ In sum, the results of this study add to the current evidence on the beneficial effects of microdosing psilocybin on mental health and mood, including among individuals with mental health concerns. Microdosing benefits: More research needed Although the study had a large sample size, the number of individuals in various subgroups according to age, gender, and substances used for microdosing was relatively small. Thus, these findings need to be replicated with larger sample sizes.https://buymushroomschocolatebars.com/?removed_item=1#quick-view Dr. Balázs Szigeti, a postdoctoral researcher at Imperial College London, also noted that the present study used a control group but placebo effects in the microdosing group cannot be ruled out. Dr. Szigeti explained: “This study used a natural history control condition, meaning that the control group did not have any treatment. This is a weak control condition, although certainly better than not having any control group as in purely observational studies.” https://www.google.com/search?q=Dr.+Szigeti+explained%3A&sourceid=chrome&ie=UTF-8 “Relative to this weak control, microdosers showed some improvements, mostly with moderate effect sizes. This means that on most scales the magnitude of the improvements was only modest. Therefore, this study helps to establish that in uncontrolled / weakly controlled studies microdosing shows some benefits,” he continued. BUY MAGIC MUSHROOMS BUY DMT BUY LSD TAPS BUY MUSHROOMS PILLS BUY KETAMINE BUY AYAHUASCA BUY MAGIC MUSHROOMS CHOCOLATE BARS BUY MDMA BUY LSD LIQUID BUY LSD GEL TAPS BUY PAIN PILLS BUY MUSHROOM CHOCOLATE BARS BUY MUSHROOM ONLINE BUY MUSHROOMS NEAR ME BUY MUSHROOMS USA BUY PSYCHEDELIC CHOCOLATE BARS BUY PSYCHEDELICS MUSHROOMS ONLINE BUY PSYCHEDELICS ONLINE USA CHOCOLATE EDIBLE FOR SALE GRAYANOTOXINS BUY MAD HONEY MAGIC MUSHROOM FOR SALE BUY PENIS ENVY MUSHROOM MUSHROOM CHOCOLATE BARS PSILOCYBIN SHROOM BARS BUY TRIPPY BARS BUY TRIPPY TREATS BARS BUY TRIPPY BOMBS TRIPPY FLIP MILK CHOCOLATE, TRIPPYFLIP Buy psilocybin mushrooms Online BUY MAGIC MUSHROOM BARS ONLINE Buy wonder bar chocolate Buy One Up Mushroom Chocolate Bar Buy PolkaDot Chocolate Bars Online Buy One Up Milk Chocolate Bar Buy Psychedelic Mushroom Online Buy Psychedelics Online PSYCHEDELIC MAGIC MUSHROOM CHOCOLATE BARS FOR SALE Microdoses of psychedelic mushrooms may improve mood and mental health Microdosing refers to the practice of regularly using small amounts of psychedelic substances that do not impair cognitive function. mushroom candy bars Chocolate Bar Shroom Good Trip Mushroom Bar chocolate bars with mushrooms chocolate bar mushroom
[toc] | [prev] | [standalone]
Page 18 of 18 — ← Prev page 1 … 16 17 [18]
Back to top | Article view | comp.lang.c
csiph-web