Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #3936
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Newsgroups | comp.lang.misc |
| Subject | Re: Compiling and linking code from different places in the file system |
| Date | 2018-03-21 07:10 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <p8t0hl$npf$1@dont-email.me> (permalink) |
| References | (9 earlier) <p8dhql$1c8t$1@gioia.aioe.org> <p8eli7$2c4$1@dont-email.me> <p8jddr$vo7$1@gioia.aioe.org> <p8q9rp$7gn$1@dont-email.me> <p8rtf9$1gsu$2@gioia.aioe.org> |
On 20/03/2018 21:14, Rod Pemberton wrote: > On Tue, 20 Mar 2018 06:31:18 +0000 > James Harris <james.harris.1@gmail.com> wrote: > >> On 17/03/2018 15:51, Rod Pemberton wrote: >>> On Thu, 15 Mar 2018 20:37:24 +0000 >>> James Harris <james.harris.1@gmail.com> wrote: >>> >>>> On 15/03/2018 10:29, Rod Pemberton wrote: >>>>> On Wed, 14 Mar 2018 11:18:02 +0000 >>>>> James Harris <james.harris.1@gmail.com> wrote: >>>>> >>>>>> On 14/03/2018 05:47, Rod Pemberton wrote: >>>>>>> On Mon, 12 Mar 2018 22:44:22 +0000 >>>>>>> James Harris <james.harris.1@gmail.com> wrote: > >>>>>> * what CPU modes or architectures each requires >>>>> >>>>> Should the code (or coder) decide this? What if the mode or >>>>> architecture isn't available? >>>> >>>> Yes, I have in mind that the coder of the source files would write >>>> the configs to describe those source files. >>> >>> How do you prevent mismatch between code and configs? I.e., parsing >>> code to generate the config would seem to be more reliable, IMO. >>> However, you've dismissed that as unreasonable because the build >>> tool chain is unfamiliar with programming languages. In which case, >>> you'd need a custom tool to parse for each language. >> >> Yes, it would be user responsibility to ensure that the configs were >> correct for the code. Frankly, even if code scanners were to be >> written for every language and dialect they could not determine >> everything that a human knows about code limits so it's probably not >> possible to automate the specification. >> > > I generally, other than 32-bit, 16-bit, etc, don't know anything about > code limits. I let the code get the information from the compiler, if > I need to know. Do you seriously memorize all the output that Enquire.c > can produce? Do you do so for multiple platforms? Each C compiler can > a completely different set of values, even on the same machine. At > some point, you'll get all that info confused. > > https://homepages.cwi.nl/~steven/enquire.html Useful link! As for what you asked, I don't memorise limits, as such. But I do write C code which is portable. Basically, beyond a certain point the code doesn't care what the machine's word size is. For example, the code could require that words be at least 16 bits wide but beyond that not care how large they are. To me, that's one of the great things about HLL code: it can be used to generate code for various machines all from one source file. > >>>> I don't intend to emit a makefile. :-) >>>> >>>> The idea is that the build system would invoke compilers and other >>>> programs as needed. >>> >>> Why would I suspect that may be more complicated than emitting a >>> makefile? >> >> It probably would. But it might be easier in the long run to have a >> custom process. It's a critical-mass issue. There comes a point where >> the effort of working with existing tools becomes so great that it >> becomes better to make a new tool. >> > > Can I take it that you believe we've reached or exceeded the > critical-mass event as arbitrarily decided upon by you? ... If so, > what pushed you over the edge? It clearly wasn't any of Banksy's > irreverent artwork/graffiti. :-) > >>>> I was thinking more about cross compiling: one platform having >>>> compilers for different targets. >>> >>> Why? We've got cloud-computing. That doesn't mean every computer >>> in the cloud must be the same architecture. >>> >>> To answer my own "Why?", there are some situations where >>> cross-compiling might be preferred, e.g., producing code for an old >>> 8-bit. >> >> AISI compilers and assemblers are standard programs which read input >> and produce output. There's no a priori requirement for them to >> produce output for the type of machine they are running on. None at >> all. > >> A compiler which emits code for a 68040, for example, could run >> on a MIPS CPU or any other turing machine. > > True. But, this is usually because the compiler has been ported to > another architecture, e.g., the MIPS CPU etc, /after/ already being made > to work for the original host microprocessor and operating system, which > the compiler on a different platform is now cross-compiling for, e.g., > the 68040. > >> I don't understand the predominance of the idea that compilers must >> produce output for the machines they run on. > > I think you'd agree that the x86 has numerous processor modes: > RM16, VM16/E0/E1, PM16, PM32, CM16, CM32, PM64, Yes, and over the years the range has acquired numerous additional registers and instruction sets. > > and numerous operating systems: > MS-DOS, PC-DOS, IBM DOS, DR-DOS, IBM OS/2, Windows 3.1, Windows NT, > Windows 98, Windows SE, Windows ME, Windows Vista, Windows 7, Windows > 8, Windows 10, Linux and various Mac OSes. > > And, there are even more environments than that, as code could be > produced specifically for various DPMI hosts, VCPI hosts, EMS hosts, > XMS hosts, and DOS Extenders used with DOS. > > So, a native compiler must generate code for the specific processor > mode and the specific host operating system or environment. This must > be working /before/ producing a cross-compiler. I.e., you must produce > output for the machine the code runs on first, in order to make sure it > works, before transferring the tool chain to another architecture, in > order to cross-compile. > > Do you agree with that sequence of events? Yes and no. Yes, the compiler has to produce object code for the minimum CPU and instruction set. No, the compiler doesn't need to produce code for different environments; it can leave that to interfacing code and the linker. > >> That last link was very useful, thanks. By showing there are many >> build-automation systems it suggests that others have found that no >> one solution is the last word on the subject. And having looked at >> some of the more promising ones and seen that they each have their >> own faults, it's reassuring in two ways: first that solutions are not >> simple and second that it can be worth writing a custom one. >> > > Are you familiar with psychology? If not, look up confirmation bias. > It's a type of cognitive bias. There are 188 known cognitive biases. > These are types of defective decision-making or faulty logic built into > the human mind. Some are more serious than others. > > https://en.wikipedia.org/wiki/Confirmation_bias > > I.e., you could've just as easily come to the conclusion that the > existence of many build-automation systems suggests that the concept of > build-automation is not an effective solution in general. You also > could've concluded that since "each have their own faults," and that > since there are many systems, that there is no perfect solution to be > found. > > In other words, your conclusions seem to be arbitrary, i.e., you're > interested in this project, so you've characterized it in the best > possible light, while disregarding the possible negatives. What you are missing in that is the journey to get to this point. I've been bothered by make's limitations for YEARS, and looked for alternatives but none of them fix the things I believe to be wrong. So it is obviously sensible to consider alternatives. And as for your suggestion that no build-automation system is perfect, that's verging on the aphoristic. The make system is good. But it has its failings. Given that other people have come up with alternatives, how do you get to the point of saying that someone else considering an alternative is succumbing to confirmation bias? And aside from the work involved, what negatives of producing a new system do you think are being disregarded (your phrase)? > >>>> What CCC would do is >>>> >>>> 1. Look for a config file in sym which tells it what each of the >>>> source files in sym is capable of. >>> >>> If the extension specifies the compiler to run, wouldn't this >>> suffice much of the time? >> >> Not really. Let me give you an example. >> >> Say we have a C file which is to be compiled and it can become an >> object file for 16-bit or 32-bit x86. The compile command for 32-bit >> "$(target)" output might be something like >> >> cc -m32 -c $(src) -o $(target) >> >> By contrast, the 'recipe' for 16-bit output might be >> >> cc -c -m16 $(src) -o /dev/null >> cc -E -m16 --sysroot=/usr/lib/bcc $(src) \ >> | /usr/lib/bcc/unproto \ >> | /usr/lib/bcc/bcc-cc1 -0 \ >> | /usr/bin/as86 -u -w -0 -n $(src) -o $(target) >> > > If they're both for x86, I'd think they'd be far more similar than > that. I.e., I'd expect both similar to the first line. If > cross-compiling or building a standalone environment, I'd suspect > something more like the later. The first (for 32-bit) is a simple compile command. The second (for 16-bit) is in two parts. Part 1 runs a simple compiler first to generate error messages. I.e. it basically uses it as a lint program because it is more informative than the 16-bit compiler. Part 2 runs the cc preprocessor (because it can do more than the one which is supplied with the 16-bit compiler) and then pipes the result through relevant stages of the 16-bit compiler. > >> Basically, the command to be run would depend on the source file type >> /and/ the target file type. The full command including all options >> would depend on a lot more, but hopefully the above shows the idea. > > I would think that you could produce links or files with different > names, that are designed to execute the compiler in different ways. > E.g., > > (normal) > cc -m32 -c $(src) -o $(target) > > (cross) > cc-x -m32 -c $(src) -o $(target) > > Simply calling cc-x instead of cc, would do all the extra stuff. Of > course, this would depend on producing a script or batch file named > cc-x. You'd probably need something a like Linux shell, bash, on > targets which don't support it. Or, you could use a makefile with > make, ISTM. I have thought of something similar but in your view what would be the advantage of doing that rather than running commands directly? > >>>> 2. Iterate over the source files in sym. For each one: >>>> >>>> 2a. Work out all the different object files we can derive from >>>> it[*]. >>>> >>>> 2b. For each one, if it exists and is up to date then do nothing. >>>> >>>> 2c. For each which is missing or is not up to date ... build it. >>>> >>>> [*] Working out what object files we can derive from each source >>>> file is something I still have to come up with a mechanism for >>> >>> Do all these languages have the ability to have multi-line or block >>> comment sections? ... If so, you could place a specification >>> within a comment block near the start of the file. Then, you just >>> need some code to detect and extract the specification. This would >>> save you from needing to actually parse the code. >>> >>> Obviously, you probably want something unique to act as a flag or >>> magic value or sentinel to key off of to find the specification. >>> And, you may need to specify it is located within the first 100 or >>> so lines of the code, etc., e.g., for C, C++, NASM: >>> >>> /* */ >>> /*<James' build-tool specification start> */ >>> /* source C */ >>> /* build-target 32-bit */ >>> /* output COFF */ >>> /* </James' build-tool specification end> */ >>> /* */ >>> >>> // >>> //<James' build-tool specification start> >>> // source C++ >>> // build-target 64-bit >>> // output PE >>> //</James' build-tool specification end> >>> // >>> >>> ; >>> ;<James' build-tool specification start> >>> ; source NASM >>> ; build-target 16-bit >>> ; output DOS .EXE >>> ;</James' build-tool specification end> >>> ; >> >> For lots of reasons I am not sure why someone would do that. > > To avoid doing 2a: > >>>> 2a. Work out all the different object files we can derive from >>>> it[*]. > > The spec tells you "all the different object files we can derive from > it," upfront, or, it could, if you so wish. Wouldn't it be better to have a program work out the possible derivatives rather than having to specify them? You were arguing before for automation but now you seem to have switched to manual specification. > >> For >> example, if you had a folder with 20 files which all had the same >> specification why would you change each one? Wouldn't it be easier to >> just say that all files in that folder had a certain specification? >> > > If that's the case "that all files in that folder had a certain > specification," couldn't you assume that the first file has the correct > spec for the entire directory? If the first is deleted or renamed, > another file, with the same specification, would be first. Or, you > could just create a single file for the entire directory, which is > typically called a makefile or build script. Yes. Having a single config file for the entire directory is basically what I suggested earlier. The only difference is that I allowed for one config file to apply to subdirectories as well as its own directory. For security it would be a config file rather than a script or makefile. > >>> Why do they need to all be built at once? Can't you build one after >>> another? If so, then you can clean, set new target, build, save >>> output files, repeat. >> >> They don't, but building all at once could be the default. > > Without cloud computing or a compute farm of servers, I don't see how > that could be the case. Well, I guess they could compile on different > cores in parallel on the same machine, but that adds extra complexity as > the host OS must support it. What if someone is compiling on a > single-core machine or single-thread operating system? You simply can't > compile all at once by default. ... Sorry, I don't mean the builds being done in parallel. I just mean that they can all be done as a result of the running of one command. I.e. the command builds them all before it finishes. That could be in parallel or concurrently or one after another. > >> What I >> have in mind is to allow the set of targets to be restricted as >> needed. For example, if the build command is CCC, as before, then >> >> CCC folder >> >> would build all possible targets for all source files in that folder. > > Yup, that should be easy to do with the parallel processing available > with cloud computing, especially if all the original host architectures > are available to build with. I doubt they'd have something as old as a > PDP-7 in their farm, but they might have a Cray or two ... Of course, > you'd expect most of these farms to be x86 or ARM. I like the scale of your ideas ... but running on a single PC would do! > >> But >> >> CCC --cconv syscall --and --cpu arm folder >> >> would only build targets which were for Arm CPUs and used the syscall >> calling convention. (That's not a defined syntax, just a possible way >> of specifying the targets.) > > If you can compile one in the cloud, you can compile them all. (*) > > (*) I don't know if that's true, but it should be. There is no reason > it couldn't be. It only takes someone with the money and vision. > > > Rod Pemberton > -- James Harris
Back to comp.lang.misc | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:10 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:28 -0500
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:44 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 23:26 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 21:59 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:45 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 10:59 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:20 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:30 +0000
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
Re: Compiling and linking code from different places in the file system rugxulo@gmail.com - 2018-03-06 18:23 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 17:29 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:39 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 10:44 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:57 -0500
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:28 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 22:44 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:47 -0400
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 10:23 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 11:30 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 11:30 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:30 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 14:32 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 16:01 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:28 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 08:59 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 19:21 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 08:08 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-16 11:12 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 16:45 +0100
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-16 16:09 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 18:42 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 18:32 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-17 21:37 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 21:00 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-18 11:39 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-18 12:29 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-19 13:38 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 05:40 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-20 11:05 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 06:03 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 18:51 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 19:55 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-23 18:03 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-23 20:13 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-24 01:30 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:48 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-26 19:42 +0100
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-26 22:35 +0100
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 12:01 +0100
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:58 +0100
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:49 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-20 18:37 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 19:33 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-21 20:35 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:10 +0100
Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:47 +0000
Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-27 00:58 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-30 19:55 +0100
Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:49 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:04 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-23 21:54 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 11:22 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 12:12 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:15 +0100
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:36 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 14:52 +0000
Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 11:06 +0000
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-14 16:52 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:38 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 09:00 +0100
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 12:54 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 11:18 +0000
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:52 +0100
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-15 06:29 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-15 20:37 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-17 11:51 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 06:31 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-20 17:14 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 07:10 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 01:38 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:10 +0000
Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 20:05 -0400
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-25 16:55 +0100
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100
csiph-web