wws@rruxd.UUCP (W W Scott) (03/14/89)
I'm trying to compile a C program under IBM's C/2 but the libraries containing the standard C functions can not be found. I read that the C libraries must be built using IBM's macro assembler before a C program can be compiled. But the macro assembler is a separate product that must be purchased. Why would they not ship the libraries as part of C/2? We're speculating that this is how IBM sells more software. Does anyone have any ideas? Wayne Scott
Kevin_P_McCarty@cup.portal.com (03/15/89)
In <357@rruxd.UUCP>, wws@rruxd.UUCP (W W Scott) writes: >I'm trying to compile a C program under IBM's C/2 but the libraries containing >the standard C functions can not be found. I read that the C libraries must >be built using IBM's macro assembler before a C program can be compiled. Where on earth did you read that? This would only apply if you were writing your own libraries in assembler. >Why would they not ship the libraries as part of C/2? We're speculating >that this is how IBM sells more software. Does anyone have any ideas? It is apparent that you are not the person who installed the compiler on your system; the installation procedure asks you which libraries you want built and where you want them put. I suggest you look in the directory where the compiler is. You should have a BIN subdirectory containing the executables, an INCLUDE subdirectory containing header files, and a LIB subdirectory containing libraries. You must also set environment variables pointing to these directories. Stop speculating and dig up the documentation describing the installation procedure; you'll find more details there. Kevin McCarty
flaps@dgp.toronto.edu (Alan J Rosenthal) (03/18/89)
In article <357@rruxd.UUCP> wws@rruxd.UUCP (W W Scott) writes: >I'm trying to compile a C program under IBM's C/2 but the libraries containing >the standard C functions can not be found.... I can't believe it! C/2 .. half a C compiler! hee hee hee hee hee hee hee hee hee hee hee hee hee hee hee hee hee hee hee
scs@adam.pika.mit.edu (Steve Summit) (03/27/89)
In article <357@rruxd.UUCP> wws@rruxd.UUCP (W W Scott) writes: >I'm trying to compile a C program under IBM's C/2 but the libraries containing >the standard C functions can not be found.... In article <8903172140.AA04348@explorer.dgp.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes: >I can't believe it! C/2 .. half a C compiler! hee hee hee This isn't even funny. There were some sample programs included with Microsoft's version 5.1 compiler which I thought I'd try (what a stupid idea). One #included <os2.h>, and then made calls to some nonportable-looking timing routines, nowhere to be found, inexplicably named DosSleep and DosTime. Whenever people develop new machines, languages, or operating systems, there is this apparently irrestible urge to invent completely new ways of doing everything. ("Let's see, we'll need routines to open a file; and get the time of day; and write characters to the screen. What shall we call them? How about OpenUpATextFile, get_time_of_day, and SCREEN$PUTCHARACTERWITHATTRIBUTEWITHOUTMOVINGCURSOR. Now we'll just rewrite all our old programs to use the new routines...") Here's a tip for all of the simpleminded reimplementors out there who think they can show off their creativity by thinking up new names for everything: YOU DON'T HAVE TO DO THIS. You don't have to invent whole sets of routines, forgetting, until later, a few important ones which then have to be crudely wedged in. You don't have to invalidate every program written so far, and commit hordes of programmers to tedious and error-prone neverending rewriting tasks. You could (take a deep breath and brace yourself; I know this is an earthshattering, revolutionaly concept) use something that already exists. If you're writing a C run-time library, and you're contemplating a feature that X3J11 covers, use the ANSI feature. If it's an OS-dependent or Unixy thing that X3J11 doesn't cover, but P1003 (Posix) does, use the Posix feature. Barring that, use any old Unix feature, or VMS, or even DOS, for all I care. But use something that exists, and might have a shred of experience behind it, and which might be utilized by a few lines of existing code. Even if the adopted solution is compatible with only 1 out of N existing machines, or operating systems, or languages, or display devices, or whatever, that's better than the 0 out of N+1 ratio you're guaranteed to get by adding yet another one. I'm not saying "stifle creativity." If you're doing something brand new, innovate to your heart's content. But things like opening files and sleeping for a certain number of seconds are ancient history; they're old-hat; they're not that interesting. Go out and make some real progress instead. Steve Summit scs@adam.pika.mit.edu
gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/27/89)
In article <10131@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >... use something that already exists. Maybe the vendor would rather sucker the users into becoming dependent on non-portable features with the result that the users get economically "locked into" that vendor's product line. It has been known to happen. I think it is up to the users (programmers in this case) to demand portable tools as you've described, possibly along with extra ones unique to each environment but clearly identifiable as such.