Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ncr-sd!hp-sdd!ucsdhub!ucsd!rutgers!mailrus!ncar!noao!arizona!sunquest!whm
From: whm@sunquest.UUCP (Bill Mitchell)
Newsgroups: comp.lang.c++
Subject: A killer problem in Oregon C++
Message-ID: <151@sunquest.UUCP>
Date: 11 Oct 88 01:28:29 GMT
Organization: Sunquest Information Systems, Tucson
Lines: 70

A little over a month ago, we purchased Oregon Software's C++ package.  Much
to my disappointment, we've encountered a serious problem with it and it looks
like we're going to have to send it back for a refund.  Over the last four
weeks, I've discussed the problem with various folks at Oregon, but they feel
that what I desire is out of the question.  What I desire is to use Sun C
run-time routines in C++ programs.

The problem lies in Oregon's handling of library routines.  The run-time
library supplied by Oregon contains routines for both for C++ run-time support
operations, such as new() and delete(), and for C library routines such as
malloc().  There are two basic problems with this approach: (1) I'd like to
have Oregon's generated code, but I also want the Sun run-time routines for
stuff like malloc, printf, etc. (2) there are a lot of potential problems when
linking using two run-time libraries that have overlapping routines.

Here's an example of a link problem: The Sun shmget(2) entry point is defined
in shmsys.o in Sun's libc.a.  The symbol malloc_at_addr is referenced in
shmsys.o, but defined in malloc.o, which also defines entry points for malloc
and free.  The Oregon run-time library has a module that defines malloc and
free, but it doesn't define malloc_at_addr.  Thus, suppose you use both
malloc and shmget in a program.  shmget isn't in the Oregon library, but malloc
is, so the module for malloc gets picked up.  After the Oregon library is
processed, the Sun library is processed.  The module for shmget is included
and it references malloc_at_addr.  The malloc_at_addr reference causes Sun's
malloc.o to be included, but in addition to defining malloc_at_addr, it defines
malloc and boom!, you've got a multiply defined symbol.

I don't know, but I think that using Sun's (or whoever's) run-time routines in
a C++ program is a pretty reasonable thing to do, but Oregon disagrees with
me on this.

I think I might try partitioning Oregon's run-time library into routines that
are and aren't used by generated code, and use a library of the former in
conjunction with the Sun C library.

My basic hope in writing this article is to generate interest in this situation
on the part of Oregon C++'s users and would-be users so that Oregon will be
convinced that using Sun run-time stuff is an ok thing to do.  I think I'd
still like to use Oregon's product, but if they stick to their guns on this,
the situation is simply unworkable.

If you've got Oregon C++, try compiling this program on your machine:

    void shmget();
    main()
    {
	shmget();
    }

You'll get some errors:

_free: ld: /lib/libc.a(malloc.o): multiply defined
_malloc: /lib/libc.a(malloc.o): multiply defined
occ: Link process terminated

If you don't like this behavior, you might want to give Oregon a call.

(Yes, if you flesh out the program with includes and parameters, you get
the same result.)

Interestingly enough, GNU's g++ is still the best C++ system that I've seen,
but I'm hesitant about committing to it for a major project.

If you're considering Oregon's product and aren't clear on the problem, feel
free to give me a call.
--------------------------------------------------------------------
Bill Mitchell				whm@sunquest.com
Sunquest Information Systems		sunquest!whm@arizona.edu
Tucson, AZ 				{arizona,uunet}!sunquest!whm
602-885-7700