Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #172151 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2023-08-13 14:53 +0100 |
| Last post | 2023-08-29 04:43 -0700 |
| Articles | 20 on this page of 306 — 31 participants |
Back to article view | Back to comp.lang.c
Build Systems Bart <bc@freeuk.com> - 2023-08-13 14:53 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-13 21:45 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-13 23:43 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-14 01:16 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 00:46 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 01:05 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 18:59 -0700
Dev on Windoze (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 02:44 +0000
Re: Dev on Windoze (Was: Build Systems) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-13 20:53 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-17 22:00 +0000
Re: Dev on Windoze (Was: Build Systems) Michael S <already5chosen@yahoo.com> - 2023-08-18 03:51 -0700
Re: Dev on Windoze (Was: Build Systems) bart c <bart4858@gmail.com> - 2023-08-18 04:58 -0700
Re: Dev on Windoze (Was: Build Systems) Matthew Ernisse <matt@going-flying.com> - 2023-08-18 13:02 +0000
Re: Dev on Windoze Phil Carmody <pc+usenet@asdf.org> - 2023-08-20 16:14 +0300
Re: Dev on Windoze "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-20 11:05 -0700
Re: Dev on Windoze (Was: Build Systems) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:16 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-14 04:03 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-14 10:14 +0000
Re: Build Systems Karl Meyer <karlmeyer25@gmail.com> - 2023-08-14 05:16 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 10:35 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 15:06 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:49 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 18:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:00 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:21 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 16:11 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 15:39 +0000
Re: Build Systems MJ OS_EXAMINE <m6502x64@gmail.com> - 2023-08-15 08:58 -0700
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 16:44 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 20:00 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 18:03 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-15 17:01 +0000
Re: Build Systems gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 17:07 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-15 23:17 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 22:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 18:49 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 13:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 23:09 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 23:36 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 15:55 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:05 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-16 01:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:37 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:15 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:16 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 16:34 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:07 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:51 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 22:25 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-17 00:15 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 01:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 02:56 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 11:21 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 23:40 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 00:43 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:45 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-18 00:24 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 17:46 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-17 18:29 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-17 19:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:55 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 14:34 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-18 15:19 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 15:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:19 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:56 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 20:57 -0700
Re: Build Systems "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> - 2023-08-27 00:01 -0700
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-27 03:34 +1300
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-27 08:32 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:58 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:58 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-27 16:52 +0200
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-27 11:59 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-18 01:49 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 02:19 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 01:21 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 18:36 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:51 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:35 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 00:35 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:54 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-19 12:30 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 13:44 -0700
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-21 17:58 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:28 +0100
Re: Build Systems Kelsey Bjarnason <kbjarnason@gmail.com> - 2023-08-22 00:12 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 11:36 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-22 13:37 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 13:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:19 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 09:30 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:51 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:36 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 16:50 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 18:06 +0100
Re: Build Systems kalevi@kolttonen.fi (Kalevi Kolttonen) - 2023-08-22 20:46 +0000
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:47 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-26 21:06 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-22 17:04 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 00:10 +0100
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 17:50 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-20 20:48 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-20 22:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 00:51 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 01:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:02 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 02:07 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 03:13 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 11:09 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 13:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:12 +0100
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-21 14:47 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 19:06 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 18:40 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:39 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-21 12:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 21:55 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-22 01:31 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 02:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 14:41 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-22 08:03 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:33 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 16:20 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-22 15:40 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 17:03 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-23 03:18 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 19:51 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:23 +0100
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-24 21:24 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 11:31 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 10:53 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 13:55 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:54 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 20:55 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-25 20:49 -0700
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 08:42 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 11:37 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 14:02 +0300
Re: Build Systems Richard Harnden <richard.nospam@gmail.com> - 2023-08-23 15:02 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:17 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 14:28 +0100
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-23 19:54 +0300
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-23 19:33 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 21:13 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-23 23:09 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-24 15:32 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 15:51 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 18:58 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-24 18:29 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-24 20:41 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 23:08 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 17:22 +0100
Re: Build Systems Spiros Bousbouras <spibou@gmail.com> - 2023-08-25 16:39 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 16:54 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 17:02 +0000
Re: Build Systems Rainer Weikusat <rweikusat@talktalk.net> - 2023-08-25 19:21 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 18:56 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 11:44 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 18:47 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-24 21:20 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-24 22:59 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 02:18 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-24 20:17 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-24 16:30 +0300
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-23 17:43 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-23 20:15 +0100
Re: Build Systems Anton Shepelev <anton.txt@gmail.moc> - 2023-08-26 18:19 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-26 21:47 -0700
Re: Build Systems Anton Shepelev <anton.txt@g{oogle}mail.com> - 2023-08-28 11:31 +0300
Re: Build Systems Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-28 06:48 -0700
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 02:11 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 11:27 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-25 13:52 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-25 15:40 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-25 20:04 +0200
Re: Build Systems candycane@f172.n1.z21.fsxnet (candycane) - 2023-08-26 00:47 +1300
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-25 21:26 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-26 01:42 +0100
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-27 01:16 +0100
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-25 05:51 +0000
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-24 23:17 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 02:52 +0000
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-21 03:02 +0000
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-21 06:05 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-21 11:32 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 14:42 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 08:09 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 15:59 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 09:38 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 18:16 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:02 +0000
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 14:13 -0700
Re: Build Systems Ike Naar <ike@sdf.org> - 2023-08-19 19:10 +0000
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-19 21:00 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 14:22 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-19 17:56 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 18:13 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:13 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 06:05 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 16:15 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:25 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-20 13:35 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-21 14:43 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-21 05:52 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 14:30 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:18 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:26 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 16:11 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 14:47 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-21 23:20 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-21 15:45 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-22 00:57 +0100
Re: Build Systems vallor <vallor@cultnix.org> - 2023-08-20 14:24 +0000
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 09:09 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-20 17:28 +0000
Re: Build Systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-19 20:26 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 14:50 +0200
Re: Build Systems Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2023-08-18 13:19 +0000
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:16 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 17:24 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 15:32 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-18 07:22 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 07:48 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:11 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 08:58 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-18 16:32 -0700
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-20 04:02 -0700
Re: Build Systems "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-08-22 12:26 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 13:56 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 05:43 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 11:23 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 02:34 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:52 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 03:56 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 13:23 +0200
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 12:55 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:52 +0200
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 02:14 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-17 15:56 +0200
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:01 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:07 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 16:20 +0000
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-17 09:31 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-17 17:24 +0000
Re: Build Systems Phil Carmody <pc+usenet@asdf.org> - 2023-08-19 14:06 +0300
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 04:39 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 16:46 +0200
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-19 16:00 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 14:15 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-20 07:25 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-20 18:03 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-17 19:51 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 16:44 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-18 08:21 -0700
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-18 15:39 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-18 17:47 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-18 10:49 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-19 15:16 +0200
Re: Build Systems bart c <bart4858@gmail.com> - 2023-08-19 07:58 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-19 09:05 -0700
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 12:48 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:36 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 21:43 +0100
Re: Build Systems Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-15 14:07 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:46 +0200
Really? (Was: Build Systems) gazelle@shell.xmission.com (Kenny McCormack) - 2023-08-15 13:15 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 09:54 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:07 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:42 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 12:14 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 05:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 15:57 +0100
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 09:10 -0700
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-14 14:49 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-14 14:39 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 11:08 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 02:56 -0700
Re: Build Systems Öö Tiib <ootiib@hot.ee> - 2023-08-15 03:23 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 11:45 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 03:53 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-15 13:15 +0100
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:22 -0700
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 01:20 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 12:57 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 12:19 +0100
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-16 15:18 +0200
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:12 +0100
Re: Build Systems Bart <bc@freeuk.com> - 2023-08-16 18:18 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:45 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 15:30 +0200
Re: Build Systems Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-15 06:58 -0700
Re: Build Systems Kaz Kylheku <864-117-4973@kylheku.com> - 2023-08-15 14:06 +0000
Re: Build Systems David Brown <david.brown@hesbynett.no> - 2023-08-15 17:08 +0200
Re: Build Systems Vir Campestris <vir.campestris@invalid.invalid> - 2023-08-15 21:46 +0100
Re: Build Systems scott@slp53.sl.home (Scott Lurndal) - 2023-08-14 15:48 +0000
Re: Build Systems Thiago Adams <thiago.adams@gmail.com> - 2023-08-15 12:16 -0700
Re: Build Systems Michael S <already5chosen@yahoo.com> - 2023-08-29 04:43 -0700
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-19 14:13 -0700 |
| Message-ID | <87h6ouivl8.fsf@nosuchdomain.example.com> |
| In reply to | #172549 |
Kaz Kylheku <864-117-4973@kylheku.com> writes:
[...]
> If you want to see what arguments are being passed to cc1, you can
> use the "strace" utility on Linux or similar syscall tracers elsewhere.
"gcc -v" shows the invoked programs and arguments.
--
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 | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2023-08-19 19:10 +0000 |
| Message-ID | <slrnue24s9.guj.ike@iceland.freeshell.org> |
| In reply to | #172541 |
On 2023-08-19, bart c <bart4858@gmail.com> wrote: > On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote: >> Ben Bacarisse <ben.u...@bsb.me.uk> writes: >> >> $ gcc -c -o a.o a.s >> >> is a perfectly legal and viable way to invoke the assembler. >> >> $ gcc -o a a.o >> >> is a perfectly legal and viable way to invoke the linker. > > You can run the assembler directly using 'as', and the linker using 'ld'. > > So how do you directly invoke the actual C compiler? Running gcc with the -v or --verbose option will show the substeps it invokes.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-08-19 21:00 +0000 |
| Message-ID | <a4aEM.562364$SuUf.473875@fx14.iad> |
| In reply to | #172541 |
bart c <bart4858@gmail.com> writes: >On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote: >> Ben Bacarisse <ben.u...@bsb.me.uk> writes: >> >bart c <bart...@gmail.com> writes: >> > >> >> >> >> >> on those other programs is anathema. >> > >> >Well (if you are talking about having to say gcc prog.c rather than gcc >> >prog) there are advantages, and none of them have anything to do with >> >how much one has to type. After all, command completion means I rarely >> >type a file name explcitly anyway. >> > >> It's worth repeating that 'gcc' is a driver program, not a compiler. >> >> So: >> >> $ gcc -c -o a.o a.s >> >> is a perfectly legal and viable way to invoke the assembler. >> >> $ gcc -o a a.o >> >> is a perfectly legal and viable way to invoke the linker. > >You can run the assembler directly using 'as', and the linker using 'ld'. > >So how do you directly invoke the actual C compiler? As if you don't already know. $ gcc -o a.o a.c or $ gcc -o a a.c
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 14:22 -0700 |
| Message-ID | <43c6a219-ad2c-4df7-8fdf-ec6c9aa54ad3n@googlegroups.com> |
| In reply to | #172557 |
On Saturday, 19 August 2023 at 22:01:09 UTC+1, Scott Lurndal wrote: > bart c <bart...@gmail.com> writes: > >On Saturday, 19 August 2023 at 15:43:02 UTC+1, Scott Lurndal wrote: > >> Ben Bacarisse <ben.u...@bsb.me.uk> writes: > >> >bart c <bart...@gmail.com> writes: > >> > > >> > >> >> > >> >> on those other programs is anathema. > >> > > >> >Well (if you are talking about having to say gcc prog.c rather than gcc > >> >prog) there are advantages, and none of them have anything to do with > >> >how much one has to type. After all, command completion means I rarely > >> >type a file name explcitly anyway. > >> > > >> It's worth repeating that 'gcc' is a driver program, not a compiler. > >> > >> So: > >> > >> $ gcc -c -o a.o a.s > >> > >> is a perfectly legal and viable way to invoke the assembler. > >> > >> $ gcc -o a a.o > >> > >> is a perfectly legal and viable way to invoke the linker. > > > >You can run the assembler directly using 'as', and the linker using 'ld'. > > > >So how do you directly invoke the actual C compiler? > As if you don't already know. > > $ gcc -o a.o a.c > > or > > $ gcc -o a a.c I thought you said gcc was the driver program? I wonder why there has to be such a big mystery about gcc (like, is it an actual compiler), why it has to work that way, or why everything to do with building C has to revolve around how Unix and gcc (and cc before that) work. Is it all decreed in the C standard? If I do this: pico hello.c the process is entirely different. But it's still C.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-19 17:56 -0700 |
| Message-ID | <87cyziil9j.fsf@nosuchdomain.example.com> |
| In reply to | #172557 |
scott@slp53.sl.home (Scott Lurndal) writes:
> bart c <bart4858@gmail.com> writes:
[...]
>>So how do you directly invoke the actual C compiler?
>
> As if you don't already know.
>
> $ gcc -o a.o a.c
That creates an executable named "a.o". Bad idea.
> or
>
> $ gcc -o a a.c
That invokes the compiler and the linker.
To invoke just the compiler:
gcc -c a.c
which creates an object file named "a.o". If for some odd reason you
want the object file to have a different name:
gcc -c a.c -o foo.o
Giving an object file a name not ending in ".o" is almost certainly a
bad idea. (That's for Unix-like systems; other systems might have a
different convention like ".obj".)
--
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 | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-19 18:13 -0700 |
| Message-ID | <c9837057-e084-4c5b-9d9a-e3ec316c2ecen@googlegroups.com> |
| In reply to | #172566 |
On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote: > sc...@slp53.sl.home (Scott Lurndal) writes: > > bart c <bart...@gmail.com> writes: > [...] > >>So how do you directly invoke the actual C compiler? > > > > As if you don't already know. > > > > $ gcc -o a.o a.c > That creates an executable named "a.o". Bad idea. > > or > > > > $ gcc -o a a.c > That invokes the compiler and the linker. > > To invoke just the compiler: > > gcc -c a.c > > which creates an object file named "a.o". If for some odd reason you > want the object file to have a different name: > > gcc -c a.c -o foo.o > > Giving an object file a name not ending in ".o" is almost certainly a > bad idea. (That's for Unix-like systems; other systems might have a > different convention like ".obj".) Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows: C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s It doesn't look very user friendly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-20 14:13 +0200 |
| Message-ID | <ubt01p$1bhkn$2@dont-email.me> |
| In reply to | #172567 |
On 20/08/2023 03:13, bart c wrote: > On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote: >> sc...@slp53.sl.home (Scott Lurndal) writes: >>> bart c <bart...@gmail.com> writes: >> [...] >>>> So how do you directly invoke the actual C compiler? >>> >>> As if you don't already know. >>> >>> $ gcc -o a.o a.c >> That creates an executable named "a.o". Bad idea. >>> or >>> >>> $ gcc -o a a.c >> That invokes the compiler and the linker. >> >> To invoke just the compiler: >> >> gcc -c a.c >> >> which creates an object file named "a.o". If for some odd reason you >> want the object file to have a different name: >> >> gcc -c a.c -o foo.o >> >> Giving an object file a name not ending in ".o" is almost certainly a >> bad idea. (That's for Unix-like systems; other systems might have a >> different convention like ".obj".) > > Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows: > > C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s > > It doesn't look very user friendly. It isn't user friendly - nor is it intended to be. It is intended that you use "gcc" (or "g++", "gfortran", or other drivers that are convenient for other gcc languages) as the driver program that will then invoke "cc1" with whatever options are needed. The options and interface for "cc1" are not considered user documentation - they are internal, might not be complete, and may change wildly between versions of gcc. It is the options for "gcc" that are documented for user usage.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-20 06:05 -0700 |
| Message-ID | <1075f829-1174-4456-b57d-74331cd61aa8n@googlegroups.com> |
| In reply to | #172573 |
On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote: > On 20/08/2023 03:13, bart c wrote: > > On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote: > >> sc...@slp53.sl.home (Scott Lurndal) writes: > >>> bart c <bart...@gmail.com> writes: > >> [...] > >>>> So how do you directly invoke the actual C compiler? > >>> > >>> As if you don't already know. > >>> > >>> $ gcc -o a.o a.c > >> That creates an executable named "a.o". Bad idea. > >>> or > >>> > >>> $ gcc -o a a.c > >> That invokes the compiler and the linker. > >> > >> To invoke just the compiler: > >> > >> gcc -c a.c > >> > >> which creates an object file named "a.o". If for some odd reason you > >> want the object file to have a different name: > >> > >> gcc -c a.c -o foo.o > >> > >> Giving an object file a name not ending in ".o" is almost certainly a > >> bad idea. (That's for Unix-like systems; other systems might have a > >> different convention like ".obj".) > > > > Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows: > > > > C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s > > > > It doesn't look very user friendly. > It isn't user friendly - nor is it intended to be. It is intended that > you use "gcc" (or "g++", "gfortran", or other drivers that are > convenient for other gcc languages) as the driver program that will then > invoke "cc1" with whatever options are needed. The options and > interface for "cc1" are not considered user documentation - they are > internal, might not be complete, and may change wildly between versions > of gcc. It is the options for "gcc" that are documented for user usage. How about 'ld'; is that supposed to be directly usable? The gcc -v option doesn't show the arguments to 'ld'; I have to determine those myself. For 'gcc hello.c', they are these (number `1 is the invocation): 1: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe 2: -plugin 3: C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/liblto_plugin-0.dll 4: -plugin-opt=C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/lto-wrapper.exe 5: -plugin-opt=-fresolution=C:\Users\44775\AppData\Local\Temp\ccZgT4Qq.res 6: -plugin-opt=-pass-through=-lmingw32 7: -plugin-opt=-pass-through=-lgcc 8: -plugin-opt=-pass-through=-lpthread 9: -plugin-opt=-pass-through=-lgcc 10: -plugin-opt=-pass-through=-lkernel32 11: -plugin-opt=-pass-through=-lmoldname 12: -plugin-opt=-pass-through=-lmingwex 13: -plugin-opt=-pass-through=-lmsvcrt 14: -plugin-opt=-pass-through=-lkernel32 15: -plugin-opt=-pass-through=-lpthread 16: -plugin-opt=-pass-through=-ladvapi32 17: -plugin-opt=-pass-through=-lshell32 18: -plugin-opt=-pass-through=-luser32 19: -plugin-opt=-pass-through=-lkernel32 20: -plugin-opt=-pass-through=-lmingw32 21: -plugin-opt=-pass-through=-lgcc 22: -plugin-opt=-pass-through=-lpthread 23: -plugin-opt=-pass-through=-lgcc 24: -plugin-opt=-pass-through=-lkernel32 25: -plugin-opt=-pass-through=-lmoldname 26: -plugin-opt=-pass-through=-lmingwex 27: -plugin-opt=-pass-through=-lmsvcrt 28: -plugin-opt=-pass-through=-lkernel32 29: -m 30: i386pep 31: --exclude-libs=libpthread.a 32: --undefined=__xl_f 33: -Bdynamic 34: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o 35: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/crtbegin.o 36: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0 37: -LC:/tdm/bin/../lib/gcc 38: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib 39: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../lib 40: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib 41: -LC:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../.. 42: C:\Users\44775\AppData\Local\Temp\ccS1MzGi.o 43: -lmingw32 44: -lgcc 45: -lpthread 46: -lgcc 47: -lkernel32 48: -lmoldname 49: -lmingwex 50: -lmsvcrt 51: -lkernel32 52: -lpthread 53: -ladvapi32 54: -lshell32 55: -luser32 56: -lkernel32 57: -lmingw32 58: -lgcc 59: -lpthread 60: -lgcc 61: -lkernel32 62: -lmoldname 63: -lmingwex 64: -lmsvcrt 65: -lkernel32 66: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/../../../../x86_64-w64-mingw32/lib/../lib/default-manifest.o 67: C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/crtend.o (This is 10.3.0; 13.2 has 'only' 53.) I suppose this is not really relevant, so long as somebody can climb to the top of this heap of complexity and plant a flag saying only 'Make`. Then it doesn't matter if its Mount Everest or an anthill. Or does it? BTW 'gcc hello.c' creates a 367KB executable; 'tcc hello.c' created a 2KB executable. Just saying... Maybe there is also a reason why -lgcc is specified four times.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-20 16:15 +0200 |
| Message-ID | <ubt762$1cngj$2@dont-email.me> |
| In reply to | #172575 |
On 20/08/2023 15:05, bart c wrote: > On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote: >> On 20/08/2023 03:13, bart c wrote: >>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote: >>>> sc...@slp53.sl.home (Scott Lurndal) writes: >>>>> bart c <bart...@gmail.com> writes: >>>> [...] >>>>>> So how do you directly invoke the actual C compiler? >>>>> >>>>> As if you don't already know. >>>>> >>>>> $ gcc -o a.o a.c >>>> That creates an executable named "a.o". Bad idea. >>>>> or >>>>> >>>>> $ gcc -o a a.c >>>> That invokes the compiler and the linker. >>>> >>>> To invoke just the compiler: >>>> >>>> gcc -c a.c >>>> >>>> which creates an object file named "a.o". If for some odd reason you >>>> want the object file to have a different name: >>>> >>>> gcc -c a.c -o foo.o >>>> >>>> Giving an object file a name not ending in ".o" is almost certainly a >>>> bad idea. (That's for Unix-like systems; other systems might have a >>>> different convention like ".obj".) >>> >>> Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows: >>> >>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s >>> >>> It doesn't look very user friendly. >> It isn't user friendly - nor is it intended to be. It is intended that >> you use "gcc" (or "g++", "gfortran", or other drivers that are >> convenient for other gcc languages) as the driver program that will then >> invoke "cc1" with whatever options are needed. The options and >> interface for "cc1" are not considered user documentation - they are >> internal, might not be complete, and may change wildly between versions >> of gcc. It is the options for "gcc" that are documented for user usage. > > How about 'ld'; is that supposed to be directly usable? "ld" is not part of gcc. It is part of an independent project, binutils, that is often used alongside gcc. (You know this, of course, and only feign ignorance.) For user convenience, gcc configurations can generally invoke a system linker or other configured linker from the gcc driver program - and in many, but not all, gcc toolchains, that will be binutils "ld". So "ld" is very much designed to be usable directly - you'll find documentation for it in the documentation for the "binutils" project.
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-08-20 09:25 -0700 |
| Message-ID | <e4bf4e3c-eb09-45d9-8702-aebaa4f7d1c4n@googlegroups.com> |
| In reply to | #172579 |
On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote: > On 20/08/2023 15:05, bart c wrote: > > On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote: > >> On 20/08/2023 03:13, bart c wrote: > >>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson wrote: > >>>> sc...@slp53.sl.home (Scott Lurndal) writes: > >>>>> bart c <bart...@gmail.com> writes: > >>>> [...] > >>>>>> So how do you directly invoke the actual C compiler? > >>>>> > >>>>> As if you don't already know. > >>>>> > >>>>> $ gcc -o a.o a.c > >>>> That creates an executable named "a.o". Bad idea. > >>>>> or > >>>>> > >>>>> $ gcc -o a a.c > >>>> That invokes the compiler and the linker. > >>>> > >>>> To invoke just the compiler: > >>>> > >>>> gcc -c a.c > >>>> > >>>> which creates an object file named "a.o". If for some odd reason you > >>>> want the object file to have a different name: > >>>> > >>>> gcc -c a.c -o foo.o > >>>> > >>>> Giving an object file a name not ending in ".o" is almost certainly a > >>>> bad idea. (That's for Unix-like systems; other systems might have a > >>>> different convention like ".obj".) > >>> > >>> Also, none of these /directly/ invoke the compiler. Using your suggestion, gcc uses an invocation like this, on Windows: > >>> > >>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe -quiet -v -iprefix C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 -auxbase hello -version -o C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s > >>> > >>> It doesn't look very user friendly. > >> It isn't user friendly - nor is it intended to be. It is intended that > >> you use "gcc" (or "g++", "gfortran", or other drivers that are > >> convenient for other gcc languages) as the driver program that will then > >> invoke "cc1" with whatever options are needed. The options and > >> interface for "cc1" are not considered user documentation - they are > >> internal, might not be complete, and may change wildly between versions > >> of gcc. It is the options for "gcc" that are documented for user usage. > > > > How about 'ld'; is that supposed to be directly usable? > "ld" is not part of gcc. It is part of an independent project, > binutils, that is often used alongside gcc. (You know this, of course, > and only feign ignorance.) Why 'of course'? Is gcc the only C implementation on the planet? The C compilers I've used most often are complete, self-contained solutions. Mine doesn't even have or use a linker. Why is so much is made of the idiosyncratic way that C works on Unix systems? Who cares that 'as' is in compartment A, cc1 is in B, ld is in C, the standard headers is in D1 and may D2, the runtime is E, gcc itself is F, and 'make' is, what, G? Just build the effing program! When I install gcc on Windows, I really, really don't care how it's organised or who is responsible for what. It should take source code at one end, and output binaries at the other.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-20 13:35 -0700 |
| Message-ID | <87zg2lh2pv.fsf@nosuchdomain.example.com> |
| In reply to | #172590 |
bart c <bart4858@gmail.com> writes:
[...]
> Why is so much is made of the idiosyncratic way that C works on Unix
> systems?
Because you keep complaining about it and misrepresenting it.
If you stop posting about it, the discussion will die out.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-08-21 14:43 +0200 |
| Message-ID | <ubvm5c$1ta8d$1@dont-email.me> |
| In reply to | #172590 |
On 20/08/2023 18:25, bart c wrote: > On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote: >> On 20/08/2023 15:05, bart c wrote: >>> On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote: >>>> On 20/08/2023 03:13, bart c wrote: >>>>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson >>>>> wrote: >>>>>> sc...@slp53.sl.home (Scott Lurndal) writes: >>>>>>> bart c <bart...@gmail.com> writes: >>>>>> [...] >>>>>>>> So how do you directly invoke the actual C compiler? >>>>>>> >>>>>>> As if you don't already know. >>>>>>> >>>>>>> $ gcc -o a.o a.c >>>>>> That creates an executable named "a.o". Bad idea. >>>>>>> or >>>>>>> >>>>>>> $ gcc -o a a.c >>>>>> That invokes the compiler and the linker. >>>>>> >>>>>> To invoke just the compiler: >>>>>> >>>>>> gcc -c a.c >>>>>> >>>>>> which creates an object file named "a.o". If for some odd >>>>>> reason you want the object file to have a different name: >>>>>> >>>>>> gcc -c a.c -o foo.o >>>>>> >>>>>> Giving an object file a name not ending in ".o" is almost >>>>>> certainly a bad idea. (That's for Unix-like systems; other >>>>>> systems might have a different convention like ".obj".) >>>>> >>>>> Also, none of these /directly/ invoke the compiler. Using >>>>> your suggestion, gcc uses an invocation like this, on >>>>> Windows: >>>>> >>>>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe >>>>> -quiet -v -iprefix >>>>> C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT >>>>> hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 >>>>> -auxbase hello -version -o >>>>> C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s >>>>> >>>>> It doesn't look very user friendly. >>>> It isn't user friendly - nor is it intended to be. It is >>>> intended that you use "gcc" (or "g++", "gfortran", or other >>>> drivers that are convenient for other gcc languages) as the >>>> driver program that will then invoke "cc1" with whatever >>>> options are needed. The options and interface for "cc1" are not >>>> considered user documentation - they are internal, might not be >>>> complete, and may change wildly between versions of gcc. It is >>>> the options for "gcc" that are documented for user usage. >>> >>> How about 'ld'; is that supposed to be directly usable? >> "ld" is not part of gcc. It is part of an independent project, >> binutils, that is often used alongside gcc. (You know this, of >> course, and only feign ignorance.) > > Why 'of course'? Is gcc the only C implementation on the planet? The "of course" is because you know that gcc is a compiler (or multiple compilers), with the actual "gcc" executable being a driver program. You know the compiler does not include the C standard library, OS headers, an assembler or a linker. You know that "as" and "ld" are commonly used with gcc, and are part of the binutils project, not part of the GCC project. You know all this because it has been explained to you, patiently, countless times. Any attempts to claim otherwise are just trolling on your part - more feeble attempts to make it look like there is a problem with gcc rather than a problem with you. > > The C compilers I've used most often are complete, self-contained > solutions. Mine doesn't even have or use a linker. Then it is not a C compiler - it is a tool that includes a C compiler amongst other things. Self-contained toolchains can often be a useful solution, and it is common to see compilers packaged alongside a library, assembler, linker, librarian, and perhaps other tools such as a debugger and profiler. If the packaging is for Windows, basic common utilities (such as make, a decent shell, and common POSIX cli programs) are also common. But as you know, many C compilers - gcc, clang, icc, and others - are merely parts of C implementations. For most users, it really doesn't matter as long as they have all the working parts - relatively few C developers care about the details of their assembler or linker. > > Why is so much is made of the idiosyncratic way that C works on Unix > systems? Who cares that 'as' is in compartment A, cc1 is in B, ld is > in C, the standard headers is in D1 and may D2, the runtime is E, gcc > itself is F, and 'make' is, what, G? Just build the effing program! The people developing the tools care. I agree that most users - C programmers in this case - often don't care. They usually get all the parts from the same source - "apt-get install", or download mingw64, or get a cross-compiler toolchain from a microcontroller manufacturer's website. However, if you want to mix and match parts, as you seem to do, it helps to know what the parts are and where they come from. (And if you didn't mean to mix and match, then it helps to know what you did wrong.) And you specifically asked about "ld", so I answered your question. Shooting the messenger and getting in a fluster just because your little tool combines a C compiler and linker in one program is not particularly helpful. > > When I install gcc on Windows, I really, really don't care how it's > organised or who is responsible for what. It should take source code > at one end, and output binaries at the other. > Oh, but you /do/ care. You care a great deal - you care that it /fails/, no matter how hard you have to work in order to make that happen.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2023-08-21 05:52 -0700 |
| Message-ID | <ec114b45-5026-43c9-aadd-f33e0bbfc8ben@googlegroups.com> |
| In reply to | #172622 |
On Monday, 21 August 2023 at 13:43:39 UTC+1, David Brown wrote: > On 20/08/2023 18:25, bart c wrote: > > On Sunday, 20 August 2023 at 15:15:45 UTC+1, David Brown wrote: > >> On 20/08/2023 15:05, bart c wrote: > >>> On Sunday, 20 August 2023 at 13:14:00 UTC+1, David Brown wrote: > >>>> On 20/08/2023 03:13, bart c wrote: > >>>>> On Sunday, 20 August 2023 at 01:57:13 UTC+1, Keith Thompson > >>>>> wrote: > >>>>>> sc...@slp53.sl.home (Scott Lurndal) writes: > >>>>>>> bart c <bart...@gmail.com> writes: > >>>>>> [...] > >>>>>>>> So how do you directly invoke the actual C compiler? > >>>>>>> > >>>>>>> As if you don't already know. > >>>>>>> > >>>>>>> $ gcc -o a.o a.c > >>>>>> That creates an executable named "a.o". Bad idea. > >>>>>>> or > >>>>>>> > >>>>>>> $ gcc -o a a.c > >>>>>> That invokes the compiler and the linker. > >>>>>> > >>>>>> To invoke just the compiler: > >>>>>> > >>>>>> gcc -c a.c > >>>>>> > >>>>>> which creates an object file named "a.o". If for some odd > >>>>>> reason you want the object file to have a different name: > >>>>>> > >>>>>> gcc -c a.c -o foo.o > >>>>>> > >>>>>> Giving an object file a name not ending in ".o" is almost > >>>>>> certainly a bad idea. (That's for Unix-like systems; other > >>>>>> systems might have a different convention like ".obj".) > >>>>> > >>>>> Also, none of these /directly/ invoke the compiler. Using > >>>>> your suggestion, gcc uses an invocation like this, on > >>>>> Windows: > >>>>> > >>>>> C:/tdm/bin/../libexec/gcc/x86_64-w64-mingw32/10.3.0/cc1.exe > >>>>> -quiet -v -iprefix > >>>>> C:/tdm/bin/../lib/gcc/x86_64-w64-mingw32/10.3.0/ -D_REENTRANT > >>>>> hello.c -quiet -dumpbase hello.c -mtune=generic -march=x86-64 > >>>>> -auxbase hello -version -o > >>>>> C:\Users\xxxxx\AppData\Local\Temp\ccJo76DR.s > >>>>> > >>>>> It doesn't look very user friendly. > >>>> It isn't user friendly - nor is it intended to be. It is > >>>> intended that you use "gcc" (or "g++", "gfortran", or other > >>>> drivers that are convenient for other gcc languages) as the > >>>> driver program that will then invoke "cc1" with whatever > >>>> options are needed. The options and interface for "cc1" are not > >>>> considered user documentation - they are internal, might not be > >>>> complete, and may change wildly between versions of gcc. It is > >>>> the options for "gcc" that are documented for user usage. > >>> > >>> How about 'ld'; is that supposed to be directly usable? > >> "ld" is not part of gcc. It is part of an independent project, > >> binutils, that is often used alongside gcc. (You know this, of > >> course, and only feign ignorance.) > > > > Why 'of course'? Is gcc the only C implementation on the planet? > The "of course" is because you know that gcc is a compiler (or multiple > compilers), with the actual "gcc" executable being a driver program. > You know the compiler does not include the C standard library, OS > headers, an assembler or a linker. You know that "as" and "ld" are > commonly used with gcc, and are part of the binutils project, not part > of the GCC project. You know all this because it has been explained to > you, patiently, countless times. Any attempts to claim otherwise are > just trolling on your part - more feeble attempts to make it look like > there is a problem with gcc rather than a problem with you. > > > > The C compilers I've used most often are complete, self-contained > > solutions. Mine doesn't even have or use a linker. > Then it is not a C compiler - it is a tool that includes a C compiler > amongst other things. > A compiler translates from one computer language to another. S a program which takes in C source and spits out Fortran would be a Co to Fortran compiler. One that spits out object code, like gcc, is a C to object code compiler. But one that spits out executable machine code, like Bart's appears to do, would also be a C compiler. Often of course C is a target language of compilers. It's very common to devise a high level language and then write a whizzylang to C compiler for it. You then leverage C's popularity to make whizzylang run almost anywhere.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-21 14:30 +0100 |
| Message-ID | <ubvosp$1tqed$1@dont-email.me> |
| In reply to | #172622 |
On 21/08/2023 13:43, David Brown wrote: > On 20/08/2023 18:25, bart c wrote: >> Why 'of course'? Is gcc the only C implementation on the planet? > > The "of course" is because you know that gcc is a compiler (or multiple > compilers), with the actual "gcc" executable being a driver program. Isn't that part supposed to be transparent? Somebody could rewrite gcc as an all-in-one program (or rename tcc.exe to gcc.exe). > You > know the compiler does not include the C standard library, OS headers, > an assembler or a linker. I once used Clang for 18 months before I realised it was using gcc's headers and linker. Then it switch to piggybacking onto MS tools, even though it's quite a hefty app already. Since then it has rarely worked. You know that "as" and "ld" are commonly used > with gcc, and are part of the binutils project, not part of the GCC > project. You know all this because it has been explained to you, > patiently, countless times. Any attempts to claim otherwise are just > trolling on your part - more feeble attempts to make it look like there > is a problem with gcc rather than a problem with you. > >> >> The C compilers I've used most often are complete, self-contained >> solutions. Mine doesn't even have or use a linker. > > Then it is not a C compiler - it is a tool that includes a C compiler > amongst other things. So what /is/ a C compiler? What exactly does it comprise? What, exactly, does it do? Does it really not include stdio.h? Where would you even get stdio.h, or windows.h, if supplied separately?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-21 15:18 -0700 |
| Message-ID | <87il98ghta.fsf@nosuchdomain.example.com> |
| In reply to | #172627 |
Bart <bc@freeuk.com> writes:
[...]
> So what /is/ a C compiler? What exactly does it comprise? What,
> exactly, does it do?
>
> Does it really not include stdio.h? Where would you even get stdio.h,
> or windows.h, if supplied separately?
This has been patiently explained to you many times. I would answer if
I believed you were interested in learning from an answer. I don't.
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-21 23:26 +0100 |
| Message-ID | <uc0ob5$22t1l$2@dont-email.me> |
| In reply to | #172641 |
On 21/08/2023 23:18, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> So what /is/ a C compiler? What exactly does it comprise? What, >> exactly, does it do? >> >> Does it really not include stdio.h? Where would you even get stdio.h, >> or windows.h, if supplied separately? > > This has been patiently explained to you many times. I would answer if > I believed you were interested in learning from an answer. I don't. > I'm interested in knowing the answer. (But I'm more interested in knowing why you think I would know it. I had to create my own headers! So there was an easy resource to download them from; who knew?) So where DO the standard headers for a Windows C compiler come from? Where does windows.h come from, as that is also required? I don't believe every compiler pinches them from the Windows SDK, as they are all different, from 20K lines to 200K lines, from one header file, to 165 unique headers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-21 16:11 -0700 |
| Message-ID | <87a5ukgfdg.fsf@nosuchdomain.example.com> |
| In reply to | #172643 |
Bart <bc@freeuk.com> writes:
> On 21/08/2023 23:18, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> So what /is/ a C compiler? What exactly does it comprise? What,
>>> exactly, does it do?
>>>
>>> Does it really not include stdio.h? Where would you even get stdio.h,
>>> or windows.h, if supplied separately?
>>
>> This has been patiently explained to you many times. I would answer
>> if I believed you were interested in learning from an answer. I
>> don't.
>
> I'm interested in knowing the answer. (But I'm more interested in
> knowing why you think I would know it. I had to create my own headers!
> So there was an easy resource to download them from; who knew?)
stdio.h really is not part of the compiler. Both stdio.h and a C
compiler are part of a C implementation.
That's the part that I'm saying has been patiently explained to you.
The details of where stdio.h comes from for a given implementation
are a different matter. I should have made that distinction more
clearly.
(A C compiler could implement the standard headers internally,
so that its response to `#include <stdio.h>` would be to insert a
collection of symbols internally rather than reaading an external
file. That would be an odd implementation, but it could be perfectly
valid. But it would still need to be able to use other headers.)
The C standard (I'm sure you have a copy of a draft) specifies
8 translation phases in section 5.1.1.2 (the number might vary
in different editions). Phases 1-4 (or maybe 1-5 or 1-6) are
typically implemented in a preprocessor, though it doesn't have to
be a separate program. Phases 1-7 are the compiler. Phase 8 is
the linker. The standard specifically says that many of the phases
are typically folded together; an implementation must behave *as if*
it implemented the phases as described.
Can you acknowledge that you understand that? It could save some time
in future discussions.
I don't know what headers you say you had to create. If you're
creating a complete C implementation, you might have to write
your own standard headers if none of the existing ones suited
your purposes.
> So where DO the standard headers for a Windows C compiler come from?
It depends on the particular implementation.
Probably the most popular C development system for Windows
is Microsoft Visual Studio (though it's mostly used for C++).
It includes multiple components, all installed together, including
a compiler, libraries, header files, a linker, etc. -- and of course
an IDE with a lot of bells and whistles.
> Where does windows.h come from, as that is also required? I don't
> believe every compiler pinches them from the Windows SDK, as they are
> all different, from 20K lines to 200K lines, from one header file, to
> 165 unique headers.
Again, it depends on the implementation. ("windows.h" is very probably
a single file; it may #include other header files.)
Windows C implementations tend to be packaged together, with the
package incorporating a compiler, runtime library, headers, etc.
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-21 14:47 -0700 |
| Message-ID | <87msykgjaa.fsf@nosuchdomain.example.com> |
| In reply to | #172590 |
bart c <bart4858@gmail.com> writes:
[...]
> The C compilers I've used most often are complete, self-contained
> solutions. Mine doesn't even have or use a linker.
[...]
Really? How does that work?
For example, this source file compiles without error:
```
extern void no_such_function(void);
int main(void) {
no_such_function();
}
```
but if I try to generate an executable from it I get an error from the
linker. If you try to generate an executable using your compiler, what
reports the error? Or is it not reported until you try to run the
program?
--
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 | Bart <bc@freeuk.com> |
|---|---|
| Date | 2023-08-21 23:20 +0100 |
| Message-ID | <uc0nvh$22t1l$1@dont-email.me> |
| In reply to | #172640 |
On 21/08/2023 22:47, Keith Thompson wrote:
> bart c <bart4858@gmail.com> writes:
> [...]
>> The C compilers I've used most often are complete, self-contained
>> solutions. Mine doesn't even have or use a linker.
> [...]
>
> Really? How does that work?
>
> For example, this source file compiles without error:
> ```
> extern void no_such_function(void);
>
> int main(void) {
> no_such_function();
> }
> ```
> but if I try to generate an executable from it I get an error from the
> linker. If you try to generate an executable using your compiler, what
> reports the error? Or is it not reported until you try to run the
> program?
>
It doesn't have a conventional linker that works with OBJ files.
Because C allows modules to be independently compiled, there needs to be
a mechanism to compile several such outputs, then combining them into an
executable.
But instead of .obj files (or .s then .o like gcc uses), it uses only
.asm files.
There are two types of external symbols that need to resolved:
(1) Symbols exported by one C module of the app and imported by another
(2) Symbols imported from an external library
The assembler I use performs the job of resolving type (1) symbols
imported from other modules: it reads multiple .asm files and produces
one .exe file.
Type (2) symbols can only come from DLL shared libraries. They are
checked off by the part that creates the EXE image, which contains a
list of DLL dependencies, and the symbols imported from each.
The parts of the assembler responsonsible for (1) and (2) probably
require 10KB of code. The LD linker is 1500KB, and the LLVM one about
64000KB.
This assembler forms part of BCC as well as being an independent tool.
Static 'linking' of OBJ files from other compilers is not possible. (Tcc
might have the same limitation.) I used to be able to do it by getting
my assembler to generate OBJ format (one file for the whole program),
and then employing a third party, real linker. That's fallen into disuse.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-08-21 15:45 -0700 |
| Message-ID | <87edjwgglh.fsf@nosuchdomain.example.com> |
| In reply to | #172642 |
Bart <bc@freeuk.com> writes:
> On 21/08/2023 22:47, Keith Thompson wrote:
>> bart c <bart4858@gmail.com> writes:
>> [...]
>>> The C compilers I've used most often are complete, self-contained
>>> solutions. Mine doesn't even have or use a linker.
>> [...]
>> Really? How does that work?
[...]
> It doesn't have a conventional linker that works with OBJ files.
[...]
> The assembler I use performs the job of resolving type (1) symbols
> imported from other modules: it reads multiple .asm files and produces
> one .exe file.
[...]
So the "linker" is incorporated into the assembler.
(This is just an observation. I'm not saying there's anything wrong
with that approach.)
--
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]
Page 11 of 16 — ← Prev page 1 … 9 10 [11] 12 13 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web