whm@sunquest.UUCP (Bill Mitchell) (10/11/88)
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-7700usenet@cps3xx.UUCP (Usenet file owner) (10/12/88)
in article <151@sunquest.UUCP>, whm@sunquest.UUCP (Bill Mitchell) says: > > A little over a month ago, we purchased Oregon Software's C++ package. Much As far as I am concerned, if you need to use compiler product N on machine M, the compiler HAS to support the standard libraries on the machine. I am astonished at Oregon's arrogance! Do they honestly believe that what they supply in terms of runtime libraries is all you would ever need to talk to the machine? Or do they supply their versions of all of the libraries in /usr/lib on the Sun? Correct me if I am wrong, but isn't the purpose of machine specific libraries to be able to develop programming that takes good advantage of the hardware/operating system? My recommendation? Run G++ (with your own libg++ (to get out of Stallman's strange copylefting)). "Why is it, everytime I see Dan Quail, I feel like buying a vowel?" -- Emo -------------------------------------------------------------------------------- | Robert Raisch - Case Center for CAEM | UseNet: {uunet,mailrus}!msudoc!raisch| | Engineering, Michigan State University| InterNet: raisch@msudoc.egr.msu.edu | | SnailNet: 1716 1/2 E. Mich Ave, 48912 | ICBMNet: 084 28 50 W / 42 43 29 N | --------------------------------------------------------------------------------
adtaiwo@royal.mit.edu (Ademola O. Taiwo) (10/13/88)
In article <854@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes: >in article <151@sunquest.UUCP>, whm@sunquest.UUCP (Bill Mitchell) says: >> >> A little over a month ago, we purchased Oregon Software's C++ package. Much > >My recommendation? Run G++ (with your own libg++ (to get out of >Stallman's strange copylefting)). Why would anyone honestly want to get out of copy[->right|<-left]. The one overriding reason I can think of is so that you can benefit from others' work without due credit to the owners of these rights, or even STEAL from the products of their sweat. If you use GNU products you have to respect the terms of the GNU license including COPY<-|->, but if you want to be a software hoarder, get a program from fellow hoarder.
mball@cod.NOSC.MIL (Michael S. Ball) (10/14/88)
(I tried to mail this, but didn't get through) Discussion of not being able to use Sun's library with Oregon C++... As far as I know, there is nothing to prevent the use of the sun version of malloc with Oregon C++. You may have to pick it up specifically in the link, but that's easy to do. If you can't do this, it is definately a bug, since it is supposed to work that way. I should know, I wrote the thing and if it isn't compatible it should be fixed. If you are having trouble with Oregon Software support personnel, call me and I will sort it out. Mike Ball TauMetric Corporation 1094 Cudahy Place, Ste 302 San Diego, CA 92110 (619)275-6381
whm@sunquest.UUCP (Bill Mitchell) (10/14/88)
In article <1255@cod.NOSC.MIL>, mball@cod.NOSC.MIL (Michael S. Ball) writes: > > As far as I know, there is nothing to prevent the use of the sun version > of malloc with Oregon C++. You may have to pick it up specifically in the > link, but that's easy to do. If you can't do this, it is definately a > bug, since it is supposed to work that way. I should know, I wrote the > thing and if it isn't compatible it should be fixed. > Mike, thanks for your note -- I'll be sure to give you a call. Extracting malloc.o from /lib/libc.a works for the particular problem I mentioned, but I don't view that solution as satisfactory in general. (I picture coding sessions punctuated with spells of digging through "nm" output to figure out what module now needs to be linked prior to the Oregon library.) I guess the question I really have to ask myself is whether Oregon seems like a good bet given my experience. All they need to do to get $5k in business from us is to partition a library, but they say it's out of the question. I just can't understand it. I was just looking at an Oregon C++ glossy and under a topic entitled "Host Integration" it says: "Oregon C++ is fully integrated with the host environment, allowing use of existing libraries". I say BULLSH*T! Well, enough complaining for now. I'll be at the C++ conference next week; maybe I'll run into someone from Oregon and be able to do some face-to-face complaining. -------------------------------------------------------------------- Bill Mitchell whm@sunquest.com Sunquest Information Systems sunquest!whm@arizona.edu Tucson, AZ {arizona,uunet}!sunquest!whm 602-885-7700
robert@pvab.UUCP (Robert Claeson) (10/14/88)
In article <854@cps3xx.UUCP>, usenet@cps3xx.UUCP (Usenet file owner) writes: > As far as I am concerned, if you need to use compiler product N on > machine M, the compiler HAS to support the standard libraries on the machine. > > I am astonished at Oregon's arrogance! Do they honestly believe that > what they supply in terms of runtime libraries is all you would ever > need to talk to the machine? Or do they supply their versions of all of the > libraries in /usr/lib on the Sun? I thought /lib/libc.a or /usr/lib/libc.a *was* the operating system interface for all languages. And I certainly want access to that interface. -- Robert Claeson, ERBE DATA AB, P.O. Box 77, S-175 22 Jarfalla, Sweden Tel: +46 758-202 50 Fax: +46 758-197 20 Email: robert@pvab.se (soon rclaeson@erbe.se)
henry@utzoo.uucp (Henry Spencer) (10/15/88)
In article <7443@bloom-beacon.MIT.EDU> adtaiwo@royal.mit.edu (Ademola O. Taiwo) writes: >Why would anyone honestly want to get out of copy[->right|<-left]. >The one overriding reason I can think of is so that you can benefit >from others' work without due credit to the owners of these rights, or >even STEAL from the products of their sweat. This depends on your definition of "steal". Not everyone agrees that Stallman's redistribution rules are a Good Thing. Nobody would object to giving GNU credit for its work, but there are people who would sort of like to be able to use it without wholeheartedly embracing the Cult Of Free Software. (If you are a True Believer, of course, such people are evil greedheads trying to shaft the poor users.) Please keep the jihad out of comp.lang.c++. -- The meek can have the Earth; | Henry Spencer at U of Toronto Zoology the rest of us have other plans.|uunet!attcan!utzoo!henry henry@zoo.toronto.edu
usenet@cps3xx.UUCP (Usenet file owner) (10/15/88)
in article <7443@bloom-beacon.MIT.EDU>, adtaiwo@royal.mit.edu (Ademola O. Taiwo) says: > Summary: Now, that's not fair. Damnit it's NOT ethical! > > In article <854@cps3xx.UUCP> usenet@cps3xx.UUCP (Usenet file owner) writes: >>in article <151@sunquest.UUCP>, whm@sunquest.UUCP (Bill Mitchell) says: >>> >>> A little over a month ago, we purchased Oregon Software's C++ package. Much >> >>My recommendation? Run G++ (with your own libg++ (to get out of >>Stallman's strange copylefting)). > > Why would anyone honestly want to get out of copy[->right|<-left]. > The one overriding reason I can think of is so that you can benefit > from others' work without due credit to the owners of these rights, or > even STEAL from the products of their sweat. > If you use GNU products you have to respect the terms of the GNU > license including COPY<-|->, but if you want to be a software hoarder, > get a program from fellow hoarder. This is neither the time nor the place to debate the Honorable Mr. Stallman's ideas. I do take offense at being called a "software hoarder" and a thief! Until the whole world comes into synch with the concept of "Free Software", the independant software developer will continue to produce products FOR SALE. As a developer myself, I would quickly go bankrupt if I were to produce my products and generously give them away. The G++ compiler is an awesome piece of work, and I use it regularly. The C++ library needed to produce C++ runnables is comparatively small, and it is the only element that, if included in a program, implys that that program is "copylefted", (as I understand it). Mr. Stallman's original concepts, (from the article long ago in Dr. Dobb's), were to offer the developer systems software that was free, efficient and available in source form. These ideas I heartily agree with. If Mr. Stallman were to have his way, the independant developer would cease to be independant. Not all of us can or will work for others to "make a living", allowing us to produce software in our free time. And most employers frown on personal development on company time. Until these conditions change, I suppose I will continue to be a "hoarder". But I assure you, were the conditions different, I would dedicate my talents, fulltime, to the Free Software Foundation. "Why is it, everytime I see Dan Quail, I feel like buying a vowel?" -- Emo -------------------------------------------------------------------------------- | Robert Raisch - Case Center for CAEM | UseNet: {uunet,mailrus}!msudoc!raisch| | Engineering, Michigan State University| InterNet: raisch@msudoc.egr.msu.edu | | SnailNet: 1716 1/2 E. Mich Ave, 48912 | ICBMNet: 084 28 50 W / 42 43 29 N | --------------------------------------------------------------------------------
preston@felix.UUCP (Preston Bannister) (10/15/88)
From article <7443@bloom-beacon.MIT.EDU>, by adtaiwo@royal.mit.edu (Ademola O. Taiwo): > Why would anyone honestly want to get out of copy[->right|<-left]. > The one overriding reason I can think of is so that you can benefit > from others' work without due credit to the owners of these rights, or > even STEAL from the products of their sweat. > If you use GNU products you have to respect the terms of the GNU > license including COPY<-|->, but if you want to be a software hoarder, > get a program from fellow hoarder. Why? I work for a company. I'd like to use g++ and libg++ in my work developing products for the company. The company will not distribute the sources for the product software that I write for competitive reasons. (In reality I very much doubt that anyone other that a few direct competitors would be interested). My understanding is that because of the above constraint, the GNU copy restrictions say I cannot use libg++. From my point of view, I'm screwed. I can't use some GNU software in my work to develop product software. (Note that non-product software, say enhancements to libg++ or g++, the company I work for would not mind my distributing). In effect I seem to be locked out using and (indirectly) contributing to the GNU software tools. Of course, I may be mistaken. If I am, I'd very much like to know. -- Preston L. Bannister USENET : hplabs!felix!preston BIX : plb CompuServe : 71350,3505 GEnie : p.bannister