Microsoft's C/C++ compiler freely available

Richard,

If you have a contact at apple managing Ruby, would you forward
a concern of mine along, or direct me (off list if appropriate)
to the proper way to report a problem with the ruby install on
OS X 10.3.1?

In rbconfig.rb, there are two oddities. First, CFLAGS includes
“-arch i386 -arch ppc”, twice. I think this is very odd.

Second, and more importantly because it initially broke my
attempts to use rbconfig.rb to autoconfigure a modified ruby
interpreter,

CONFIG[“LIBRUBY_A”] = “lib$(RUBY_INSTALL_NAME).a”
CONFIG[“LIBRUBY_SO”] = “lib$(RUBY_INSTALL_NAME).so.$(MAJOR).$(MINOR).$(TEENY)”
CONFIG[“LIBRUBY_ALIASES”] = “lib$(RUBY_INSTALL_NAME).so”
CONFIG[“LIBRUBY”] = “$(LIBRUBY_A)”
CONFIG[“LIBRUBYARG”] = “$(LIBRUBY_A)”

however, “.so” is not a shared library extension on these
machines (dylib is the proper extension) and libruby.a is
not installed (apparently apple dislikes static linking).
It would be great if I could test for the existence of
LIBRUBY_SO in libdir, or just compile with LIBRUBYARG. It’s
hard for me to figure out how to use these rbconfig entries
to automatically discover how to build and install add-ons,
and I don’t remember having this difficulty with fink’s ruby
on jaguar.

thanks,
-neil

···

On Sun, Nov 23, 2003 at 05:31:50AM +0900, Richard Kilmer wrote:

I tried working with Apple to do this (with special thanks
to James Duncan Davidson) but it was just too late. They
had already committed to golden master before 1.8 was
finalized :frowning:

Well, I love it. It makes good code, fairly fast, not too large, it
complies things I’d expect it would, and it has a significant collection of
options. It comes with a debugger. I like the --Wall flag. I think that
it’s conceptually better than the ‘lint’ program used by other unices (or is
it just Sun?). I don’t like the idea of using different programs for
compiling and syntax checking, since they might have slightly different
ideas of what constitutes good code.

What problems have you had with it?

Cheers,

···

On Mon, Nov 17, 2003 at 07:00:52AM +0900, Chris Thomas wrote:

I don’t use MinGW for the simple reason that I don’t use Windows. My
comments and my views come from gcc under Linux, Solaris and AIX.
Under
these systems, gcc is fantastic. Certainly better than the Sun
compiler.
I find it easier to use, and much more dependable.

That may not be difficult. Historically, Unix vendor compilers have
tended to suck. IMHO, GCC is adequate. I wouldn’t call it “fantastic.”
They’re working on it, however. Each release is an improvement.


Daniel Carrera | Aleph-0 bottles of beer on the wall, Aleph-0 bottles
PhD student. | of beer. Take one down, pass it around, Aleph-0
Math Dept. | bottles of beer on the wall…
UMD. | Aleph-0 -- from Wolfram MathWorld

Okay, we’re getting way OT here…

(…) I like the --Wall flag. I think that
it’s conceptually better than the ‘lint’ program used by other unices (or is
it just Sun?). (…)

Nope(*). lint by itself is a very nice tool for checking code for, let’s say
valid but dubious C code. Consider the following two examples:

switch (ayaken) {
case BANZAI:
fprintf(stderr, “woohoo! banzai!\n”);
default:
abort();
}

and

switch (ayaken) {
case BANZAI:
fprintf(stderr, “woohoo! banzai!\n”);
/* FALLTHROUGH */
default:
abort();
}

gcc -Wall won’t complain about either of these (except BANZAI/ayaken
might be an enum and we don’t cover all of it here), but the second
case is lint-safe. It also documents that it is no forgetting of the
break;. lint checks code on another dimension than gcc. It also catches
(some/many/an awful lot of) problems gcc doesn’t/can’t/won’t ever. The
use of lint is totally orthogonal to (g)cc -W. I think there’s
a fair amount of documentation about the use of lint and where it makes
sense and where it doesn’t. AFAIK there’s even an O’Reilly Book (Code
checking with lint or sth similar).

I wouldn’t call gdb (an absolutely orthogonal tool not having anything
to do with gcc except for reading debugging information from the executable
which gcc put there – any compiler can do that) a useless tool either …

Nor gprof, dmalloc or other allocation checker (programs or libraries).
Those are just a bunch of development tools, and using them wisely, and
knowing how to use them, WILL improve the quality of (C-) code you are
writing. Agreeing to their standards (most of the time) means agreeing to
what commonly is viewed as ‘good’ C-Code.

With kind regards,

-Martin

(*): Any unix should have a lint, really. BSD has one, I suppose linux
has one, too (mutter: although my last base installation didn’t even have
RCS!!!), and it’s fine solaris has one, too.

···

On Mon, Nov 17, 2003 at 07:37:03AM +0900, Daniel Carrera wrote: