dwg@bpdsun1.uucp (David W. Glessner) (09/18/90)
I'm trying to get GNU Make 3.58 running on HPUX 7.0 for an HP9000/330. Command used to create GNU Make: make defines='-DUSG -DUSGr3 -DHPUX -DHAVE_SYS_WAIT' LOADLIBES=-lPW' After changing a "char *memcpy" to "void *memcpy" in arscan.c, "./make" crashed with "IOT trap (core dumped)". Have any of you seen this? Are there any patches for GNU Make on HPUX? PS: Why don't HP9000s have the dbx debugger? -- David WU9A quintro!bpdsun1!dwg@lll-winken.llnl.gov uunet!tiamat!quintro!bpdsun1!dwg
zlsiial@mcc.ac.uk (A.V. Le Blanc) (09/20/90)
I have GNU make 3.58 running under HP-UX 7.0. I compiled it with gcc 1.37.1, using either the notive or the non-native version of the compiler; the non-native version produces a smaller binary. In the Makefile I changed CFLAGS from -g to -O and made LDFLAGS null. I set defines = -DUSG -DUSGr3 -DHPUX -DHAVE_SYS_WAIT -DHAVE_DUP2 LOAD_AVG = -DKERNEL_FILE_NAME=\"/hp-ux\" In arscan.c I removed the reference to memcpy (line 39) and the open, close, etc. references (line 48). In default.c I changed line 108 to read "$(COMPILE.p) $<", to make it work with the HP Pascal compiler. In job.c I removed the declarations of fork, wait, and execve (line 77). In make.h I deleted the references to pipe, close, open, etc. (line 128). In remake.c I deleted the references to open, fstat, read, etc. (line 31). No problems have surfaced yet despite heavy use of GNU make. Yours, A. V. Le Blanc refs to pipe, close, open, etc.
paul@mecazh.uu.ch (Paul Breslaw) (09/21/90)
dwg@bpdsun1.uucp (David W. Glessner) writes: > I'm trying to get GNU Make 3.58 running on HPUX 7.0 for an HP9000/330. Should be no problem. > Command used to create GNU Make: > make defines='-DUSG -DUSGr3 -DHPUX -DHAVE_SYS_WAIT' LOADLIBES=-lPW' -DUSG correct -DUSGr3 wrong - HP-UX isn't Release 3 -DHPUX correct -DHAVE_SYS_WAIT correct LOADLIBES=-lPW wrong - libPW should be avoided like the plague Another plague to avoid is CFLAGS = -O. Use CFLAGS = +O1 after you have checked that the program goes. The -O option only exists so the folks at HP can make slow core dumps :-) > Are there any patches for GNU Make on HPUX? None needed. > PS: Why don't HP9000s have the dbx debugger? NIH. Paul Breslaw -- Paul Breslaw, Mecasoft SA, | telephone : 41 1 362 2040 Guggachstrasse 10, CH-8057 Zurich, | e-mail : paul@mecazh.uu.ch Switzerland. | mcsun!chx400!mecazh!paul
mjs@hpfcso.HP.COM (Marc Sabatella) (09/22/90)
> LOADLIBES=-lPW wrong - libPW should be avoided like the plague I'm not familiar with GNU Make, so I don't know why this dependency was specified, but... There are some routines in libPW.a that are not defined anywhere else in HP-UX. You may have no choice but to use that library, if you get unresolved externals without it. Also, the behavior of some standard C library routines is subtly different if you use the libPW version; GNU make may depend on it. >Another plague to avoid is CFLAGS = -O. Use CFLAGS = +O1 after you have >checked that the program goes. The -O option only exists so the folks >at HP can make slow core dumps :-) I'm sorry you feel that way. We do our best to fix all bugs that are reported against the optimizer. There are very few in 7.0 on the Series 300. We can't fix them if people avoid using the optimizer rather than submit bug reports, though. >> PS: Why don't HP9000s have the dbx debugger? > >NIH. Correct. Debuggers are non-standard; some of us happen to like xdb better. The biggest argument in favor of dbx is that some poeple may have become accustomed to its syntax. dbx does not have as full a feature set as does xdb, and I for one tend to use xdb's extra feautres a lot. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (09/22/90)
I'm sorry you feel that way. We do our best to fix all bugs that
are reported against the optimizer. There are very few in 7.0 on
the Series 300. We can't fix them if people avoid using the
optimizer rather than submit bug reports, though.
>> PS: Why don't HP9000s have the dbx debugger?
>
>NIH.
Correct. Debuggers are non-standard; some of us happen to like
xdb better. The biggest argument in favor of dbx is that some
poeple may have become accustomed to its syntax. dbx does not
have as full a feature set as does xdb, and I for one tend to use
xdb's extra feautres a lot.
It would be nice if HP changed xdb and cdb to use the same debugging
information format (and understand the old one for compatibility) as
dbx. In this way dbx could be ported by the users who wanted it.
Furthermore gdb, in my opinion a much better debugger written by the
Free Software Foundation, would have a cleaner port. Currently gcc
has to use its own assembler and linker in order to put the debugging
information on the object file that gdb will understand. The relative
merits of dbx, gdb, and xdb/cdb can be argued over forever, since they
are a matter of taste. I prefere the gcc/gdb combination because it
allows me to debug fully optimized (-O) code, and gdb works nicely
from within GNU Emacs.piet@cs.ruu.nl (Piet van Oostrum) (09/26/90)
>>>>> In article <JINX.90Sep22103621@chamarti.ai.mit.edu>, jinx@zurich.ai.mit.edu (Guillermo J. Rozas) (GJR) writes:
GJR> It would be nice if HP changed xdb and cdb to use the same debugging
GJR> information format (and understand the old one for compatibility) as
GJR> dbx. In this way dbx could be ported by the users who wanted it.
It would also help if HP documented the debugger table format in the a.out
files. And the assembler syntax that goes with it. This would allow someone
to port gdb to use the HP-UX a.out format.
--
Piet* van Oostrum, Dept of Computer Science, Utrecht University,
Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands.
Telephone: +31 30 531806 Uucp: uunet!mcsun!ruuinf!piet
Telefax: +31 30 513791 Internet: piet@cs.ruu.nl (*`Pete')allen@gigem.ssc.gov (Mike Allen) (09/27/90)
>>>>> On 22 Sep 90 14:36:21 GMT, jinx@zurich.ai.mit.edu (Guillermo J. Rozas) said: In article <JINX.90Sep22103621@chamarti.ai.mit.edu> jinx@zurich.ai.mit.edu (Guillermo J. Rozas) writes: >> PS: Why don't HP9000s have the dbx debugger? > >NIH. [...stuff deleted] Guillermo> Furthermore gdb, in my opinion a much better debugger written by the Guillermo> Free Software Foundation, would have a cleaner port. Currently gcc Guillermo> has to use its own assembler and linker in order to put the debugging Guillermo> information on the object file that gdb will understand. The relative Guillermo> merits of dbx, gdb, and xdb/cdb can be argued over forever, since they Guillermo> are a matter of taste. I prefere the gcc/gdb combination because it Guillermo> allows me to debug fully optimized (-O) code, and gdb works nicely Guillermo> from within GNU Emacs. Two more reasons to use gdb: 1) It can be used to debug C++ code (at least code compiled with g++) 2) gdb runs on all our machines (Masscomp, HP, NeXT, Sun) so I don't have to learn a different debugger for each vendor. How about some support for GNU products by HP? -- =============================================================================== Michael E. Allen al tadin et khaverakh 'ad shetagi'a limkomo
mjs@hpfcso.HP.COM (Marc Sabatella) (09/28/90)
>Two more reasons to use gdb: >1) It can be used to debug C++ code (at least code compiled with g++) Ah, but xdb (more particularly xdb++) supports HP C++, and from what I have heard does a much better job than gdb/g++ (I have no personal experience here). >How about some support for GNU products by HP? The GNU license agreement pretty much forbids us from providing any reasonable kind of support. In particular, we could not sell any of it (only give it away), so it would be hard to fund the support. Actually, no one has really managed to make sense out of Stallman's copyleft from a legal standpoint; we are forced to assume the most restrictive interpretation. That, plus we have a significant investment in our products, and many customers have an investment in some of our value added features like FPA support, Fortran, etc. At best we would have to support both our own products and Gnu's, and we don't have the resources for that. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me
wayne@dsndata.uucp (Wayne Schlitt) (09/30/90)
In article <7370218@hpfcso.HP.COM> mjs@hpfcso.HP.COM (Marc Sabatella) writes: > > >How about some support for GNU products by HP? > > The GNU license agreement pretty much forbids us from providing any reasonable > kind of support. In particular, we could not sell any of it (only give it > away), so it would be hard to fund the support. the gnu license doesnt forbid you (or anyone else) from providing support. on the contrary, it, and the manifesto talk a great deal about support is one of the things that you should be able to charge money for. the only thing you cant do is make changes to the programs, distribute those programs and not provide other people with the source to those changes. you _can_ charge for distributing those changes though. > > Actually, no one has really managed to make sense out of Stallman's copyleft > from a legal standpoint; we are forced to assume the most restrictive > interpretation. lots of people have made sense out of stallman's copyleft. DG, Next, and surprisingly Apple all distribute gnu software in one form or another. > That, plus we have a significant investment in our products, and many customers > have an investment in some of our value added features like FPA support, > Fortran, etc. [ ... ] that, and paranoid lawyers are probably the real reason... actually, it really surprises me that HP doesnt distribute gnu products. the have given the FSF quite a few computers and a fair amount of money. it is obvious that hp people in fairly high places know about the FSF and support it. -wayne
tt@euler.jyu.fi (Tapani Tarvainen) (09/30/90)
In article <WAYNE.90Sep29171340@dsndata.uucp> wayne@dsndata.uucp (Wayne Schlitt) writes: > actually, it really surprises me that HP doesnt distribute gnu > products. the have given the FSF quite a few computers and a fair > amount of money. Me too. I might add that a major reason I like HP9000s is that many GNU products have been quite easy to port (especially emacs -- I had to use vi (aarrrgh!) a couple of times with our first before I got it to a state where I could get emacs running). Considering that HP already distributes stuff that doesn't get their full support ("User Contributed" stuff), it shouldn't be too hard to provide a GNU tape as well. (Any one else want ready-to-run customized-for-HP GNU stuff? I for one would consider that worth money, even without support.) -- Tapani Tarvainen (tarvaine@jyu.fi, tarvainen@finjyu.bitnet)
mjs@hpfcso.HP.COM (Marc Sabatella) (10/02/90)
NOTE: I am not speaking for HP here, just spouting my own personal prejudices. >the gnu license doesnt forbid you (or anyone else) from providing >support. on the contrary, it, and the manifesto talk a great deal >about support is one of the things that you should be able to charge >money for. the only thing you cant do is make changes to the >programs, distribute those programs and not provide other people with >the source to those changes. you _can_ charge for distributing those >changes though. I had something different in mind here. Say I make substantial improvements to a Gnu product. I sell it to a few customers. I give away the source, which is then distributed freely over the net. Now everyone has access to my improvements. Why would people continue to buy from HP if they could just get the latest and greatest versions of everything for free? Well, one might say they would buy it so that they could get HP support, but who needs HP support if everyone has the source? Worse, people may expect to HP to support their locally hacked versions of tools we supplied source to, and that would be difficult. So we could well end up in a situation where no one actually bought our product any more, hence we couldn't justify the fincancial resources to support it. I do agree that for simple tools like "grep" and "make", this is not really a concern. We don't expect to make a profit from these. But what about our C++ compiler, which we do sell as a separate product? If we sold g++ unmodified, then perhaps we wouldn't need to support it, but realistically, we'd want to add our own value to the product, sell it, and use the profits in part to pay for the support. >lots of people have made sense out of stallman's copyleft. DG, Next, >and surprisingly Apple all distribute gnu software in one form or >another. That doesn't mean they have it completely straightened out, it just means they have decided they can probably get away with what they are doing. And again, I agree that for simple tools, there is no harm and probably value. On the other hand, you don't need HP to supply you these sources; you can get them anywhere. Any effort spent by HP in collecting and distributing these sources is effort that could have been spent in adding value to products you could not have gotten from other sources. This is admittedly not that great a concern. But consider this. We currently use the same backend source for both our Fortran and C compilers. This makes testing, maintenance, and adding value a lot easier. Now suppose we roll to Gnu's C compiler. We might well want to retrofit our Fortran front end to Gnu's backend. Would we be required to give out sources to our Fortran front end? This is unclear to me. Yet our Fortran front end is one of our major competitive advantages over other companies - we have implemented more VAX extensions than anyone else, even the compiler for DEC's own RISC workstation. If we had to give away these sources (obviously we have no patents to protect this stuff, after, it is only reverse engineered to mimic the VAX compiler), we could easily lose that advantage. Sorry for flying off the handle a little bit earlier. I've been doing that a lot lately. -------------- Marc Sabatella (marc@hpmonk.fc.hp.com) Disclaimers: 2 + 2 = 3, for suitably small values of 2 Bill and Dave may not always agree with me