MAKE utility for openVMS?
wo...@yahoo.com
I'm looking a MAKE utility for openVMS Alpha 7.1 system, could someone
please tell me where I can get it? Thanks a lot!
Owen
Jim
<wo...@yahoo.com> wrote in message
news:dlga0u$sbt$1...@news-srv1.vanderbilt.edu...
Jim
Tim E Sneddon
There are a few:
o. MMS - a make like utility from DEC/Compaq/HP that is part of DECset.
This one costs money.
See: http://h71000.www7.hp.com/commercial/decset/decset_index.html
o. MMK - MadGoat Make. This is a free, MMS compatible make utility. IMHO
it is a whole lot better that MMS.
o. gmake - This is part of GNV toolset.
See: http://h71000.www7.hp.com/portability/GNV.html
o. pmake - Did have a copy of this, but don't think I ever used it. There
are binaries at the address below, don't know about sources
though. It seems to be used to build Tcl on VMS.
See: ftp://sapodilla.rsmas.miami.edu/pub/VMS-tcl/
o. Jam - Although not a 'make' as such it is quite a powerful build tool
along the same lines as 'make'. From what I understand CA use
this for building INGRES.
See: http://www.perforce.com/jam/jam.html
o. Ant - Once again, not really a make, but listed for completeness. This
is used for building Java stuff. Can be found within NetBeans and
as part of CSWS_JAVA.
See: http://h71000.www7.hp.com/openvms/products/ips/apache/csws_java.html
http://h71000.www7.hp.com/openvms/products/ips/netbeans/
http://ant.apache.org
I'm sure there are others, but these are the ones I have exposure to. I believe that
there may be others on the Freeware.
Hope this was helpful.
Regards, Tim.
Bart Zorn
why one doesn't need MAKE?
Bart Zorn
Joseph Huber
> I'm looking a MAKE utility for openVMS Alpha 7.1 system, could someone
> please tell me where I can get it? Thanks a lot!
It is in the GNV distribution at the HP OpenVMS site,
though probably not back to VMS 7.1 .
A version for older VMS systems (make 3.60) is also at Hunters FILESERV at
http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=make
--
Joseph Huber , Muenchen,Germany: http://www.huber-joseph.de/
goath...@goatley.com
Joseph Huber wrote:
>
> It is in the GNV distribution at the HP OpenVMS site,
> though probably not back to VMS 7.1 .
> A version for older VMS systems (make 3.60) is also at Hunters FILESERV at
>
> http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=make
>
Thanks, Joseph. The full URL is actually:
Currently, you'll get an accvio if some of the parameters are missing.
I'll try to modify
the search program to be more forgiving.
Hunter
Joseph Huber
> Thanks, Joseph. The full URL is actually:
>
> http://vms.process.com/scripts/fileserv/fileserv_search.exe?package=make&description=&author=&system=Either&language=All&RD=&RM=&RY=
>
> Currently, you'll get an accvio if some of the parameters are missing.
> I'll try to modify
> the search program to be more forgiving.
Thanks for the hint, I was pasting the URL in my news editor and forgot the
second half.
Larry Kilgallen
> This seems to me not a very helpful answer. Could you elaborate a bit
> why one doesn't need MAKE?
Whereas yours seems to me not a very helpful answer, as you do not quote
any context regarding "this". Never assume everybody else's newsreader
is the same as yours.
Bill Gunshannon
Whoa.... Cut him a little slack, Larry.
He asked for a version of MAKE fro VMS and somebody reply was a simple,
"You don't need it." With no alternatives or explanation offered.
As he said, not very helpful. And probably not very accurate either.
I realize VMS has alternatives, but someone who is not familiar with
VMS won't know this. And, if you are already familiar with MAKE and
don't know any of the VMS equivalent systems it is very likely easier
to install a version of MAKE than to learn a new system, especially if
you are working on what is probably a one up project. Or, possibly
the project already has a Makefile which would make MAKE the real
correct answer tot he question.
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Larry Kilgallen
> In article <Tur6mk...@eisner.encompasserve.org>,
> Kilg...@SpamCop.net (Larry Kilgallen) writes:
>> In article <1132212678.1...@g14g2000cwa.googlegroups.com>, "Bart Zorn" <bart...@yahoo.com> writes:
>>> This seems to me not a very helpful answer. Could you elaborate a bit
>>> why one doesn't need MAKE?
>>
>> Whereas yours seems to me not a very helpful answer, as you do not quote
>> any context regarding "this". Never assume everybody else's newsreader
>> is the same as yours.
>
> Whoa.... Cut him a little slack, Larry.
>
> He asked for a version of MAKE fro VMS and somebody reply was a simple,
> "You don't need it." With no alternatives or explanation offered.
Who replied in that fashion ?
In what post ?
That should be given for context. Posts do not arrive in the same order
at all newsreaders, and some do not arrive at all.
wo...@yahoo.com
wishes to all!
<wo...@yahoo.com> wrote in message
news:dlga0u$sbt$1...@news-srv1.vanderbilt.edu...
wo...@yahoo.com
"Bill Gunshannon" <bi...@cs.uofs.edu> wrote in message
news:3u3mctF...@individual.net...
wo...@yahoo.com
Thank you very much for the infomation! I've got a GNU Make seemingly
working now!
Best wishes,
Owen
"Tim E Sneddon" <tesn...@bigpond.com> wrote in message
news:1132188228.1a9cdfba73...@fe5.teranews.com...
wo...@yahoo.com
yours also :)
Best,
Owen
"Joseph Huber" <hu...@NOBODY-mppmu.mpg.de> wrote in message
news:I4hvVVn1$Z...@vms.mppmu.mpg.de...
Bill Gunshannon
Kilg...@SpamCop.net (Larry Kilgallen) writes:
> In article <3u3mctF...@individual.net>, bi...@cs.uofs.edu (Bill Gunshannon) writes:
>> In article <Tur6mk...@eisner.encompasserve.org>,
>> Kilg...@SpamCop.net (Larry Kilgallen) writes:
>>> In article <1132212678.1...@g14g2000cwa.googlegroups.com>, "Bart Zorn" <bart...@yahoo.com> writes:
>>>> This seems to me not a very helpful answer. Could you elaborate a bit
>>>> why one doesn't need MAKE?
>>>
>>> Whereas yours seems to me not a very helpful answer, as you do not quote
>>> any context regarding "this". Never assume everybody else's newsreader
>>> is the same as yours.
>>
>> Whoa.... Cut him a little slack, Larry.
>>
>> He asked for a version of MAKE fro VMS and somebody reply was a simple,
>> "You don't need it." With no alternatives or explanation offered.
>
> Who replied in that fashion ?
-----------------------------
Subject: Re: MAKE utility for openVMS?
Newsgroups: comp.os.vms
Date: Thu, 17 Nov 2005 00:44:03 GMT
Organization: SBC http://yahoo.sbc.com
From: "Jim" <j...@nospam.com>
<wo...@yahoo.com> wrote in message
news:dlga0u$sbt$1...@news-srv1.vanderbilt.edu...
In truth, you really don't need MAKE.
Jim
----------------------------
>
> In what post ?
>
> That should be given for context.
Hard to give context when the reply had none. One line basicly blowing
the guy off. Not much to be gained quoting that. And, of course, the
references for the whole thread are there.
> Posts do not arrive in the same order
> at all newsreaders, and some do not arrive at all.
Any newsserver that doesn't get all the news needs a new administrator.
Order is irrelevant as long as you have all the references to rebuild the
thread, either automatically by the newsreader software or by hand if
necessary. Maybe eisner needs a real newsreader. :-)
In any case, people without anything to offer should just hit the next
button on their news reader. I would never presume to assume that
someone who asked for something didn't really need it. I don't know
about you, but I don't usually ask for things I don't need.
Larry Kilgallen
> In article <q41Jd9...@eisner.encompasserve.org>,
> Kilg...@SpamCop.net (Larry Kilgallen) writes:
>> In what post ?
>>
>> That should be given for context.
>
> Hard to give context when the reply had none. One line basicly blowing
> the guy off. Not much to be gained quoting that. And, of course, the
> references for the whole thread are there.
Indicating who posted and what they said should take very little space then.
> Order is irrelevant as long as you have all the references to rebuild the
> thread, either automatically by the newsreader software or by hand if
> necessary. Maybe eisner needs a real newsreader. :-)
ANUNEWS works quite well when posters follow netiquette.
No poster should assume that everyone runs software identical to
their own.
Dave Froble
Got to side with Larry. If you're addressing something, at least
something of what you're addressing should be included in the post.
--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. Fax: 724-529-0596
DFE Ultralights, Inc. E-Mail: da...@tsoft-inc.com
170 Grimplin Road
Vanderbilt, PA 15486
Z
>>I'm looking a MAKE utility for openVMS Alpha 7.1 system, could someone
>>please tell me where I can get it? Thanks a lot!
> In truth, you really don't need MAKE.
A fully functional version of make would reduce by days, perhaps weeks,
the amount of time it takes to build (compile,link) portable code
packaged for Unix/Linux on VMS.
Martin Vorlaender
This is what the people behind GNV try to do, as *ix makefiles typically
contain numerous unixisms that make them useless in an environment without
a *ix shell. "portable"? Only between flavors of *ix.
And talking about environments, the number of projects I see that use
autoconf/automake grows. And adapting those config.h.in files for VMS is
sometimes just as bad as tweaking the makefile.
So, a unixy make is just one piece of the puzzle.
cu,
Martin
--
| Martin Vorlaender | OpenVMS rules!
Microsoft's answer | work: m...@pdv-systeme.de
to OpenVMS is | http://www.pdv-systeme.de/users/martinv/
Windows NT 10.0. | home: mar...@radiogaga.harz.de
Dave Froble
Not having ever seen such a utility, I cannot discuss it in detail.
However, days? weeks? Cannot comprehend. Is this stuff all bloatware?
JF Mezei
> Not having ever seen such a utility, I cannot discuss it in detail.
> However, days? weeks? Cannot comprehend. Is this stuff all bloatware?
If you have 500 source code modules, equal amount of includes with about
20 that need to be created on-site based on your software configuration,
then yes, the make utility is needed.
It isn't enough to CC *.C in that directory. Some modules need to have
special CC commands, others don't. And not everytrhing is necessarily
linked as a single .EXE. Maybe you are creting 15 .EXEs.
Without the MAKE utility, you are stuck trying to interpret the unix
makefiles and create your own makefile (either .COM or other). And this
means that with every new version of that software, you need to go
through the work again.
Bob Koehler
>
> Not having ever seen such a utility, I cannot discuss it in detail.
> However, days? weeks? Cannot comprehend. Is this stuff all bloatware?
The code, the build files, the support data, ...
All full of UNIX assumptions.
Like:
you can change directores by appending /.. or /able or /../able
you need a definition for ln
you'll be putting the executable in /usr/local/bin
...
Getting a similar compiler, and a similar make utility is the
starting point for porting this stuff.
Larry Kilgallen
Leaving only the time to debug it and rid it of its Unix assumptions.
But from reports in this newsgroup, lots of porters omit that step
anyway.
John Malmberg
>
> And talking about environments, the number of projects I see that use
> autoconf/automake grows. And adapting those config.h.in files for VMS is
> sometimes just as bad as tweaking the makefile.
>
> So, a unixy make is just one piece of the puzzle.
The main piece of the puzzle for GNV to generate a config.h for many
projects is getting a current config.guess file.
$search config.guess "ia64","vms"/match=and
If you do not see any matches, the config.guess for that package is out
of date. Someone seems to have been updating the config.guess files for
several of the GNU packages though. What is curious is that some of
them have been updated to know about "alpha-hp-vms" but not
"ia64-hp-vms". In most cases, I am seeing "ia64-dec-vms".
autoconf requires changes to Perl on VMS so that Perl can spawn
multi-line bash commands. Currently Perl on VMS will try to issue them
as DCL commands.
Configure scripts may hang under GNV Bash because they are sending files
to the sed editor that are larger than what can be stored completely in
an OpenVMS MAILBOX. In some cases this only shows up after the first
run of Configure because it is validating the config.status file. In
that case deleting the config.status file allow the Configure script to
be re-run. In other cases, the Configure script will need to be modified.
I am anticipating this issue will be fixed in an future version of GNV. :-)
Configure scripts also generally require the following line just before
they are run to prevent their tests from being attempted as DCL commands.
bash$ export GNV_DISABLE_DCL_FALLBACK=1
The use of --disable-dependency-tracking as a parameter to the Configure
command may also be required for proper generation of the Makefile. You
may also need to use other Configure options to override tests. Run the
Configure script with the "--help" option to get a list of the options.
Some options are controlled by the export of shell symbols before
running the script.
Also, the CC/GCC program in GNV will use the current setting of the CC
symbol. The CC symbol may need to be modified so that the C compiler
will behave more like UNIX expects.
cc :== cc/names=(shortened,as_is)
For simple projects, you can add a "/FIRST_INCLUDE=path:vms_inc_first.h"
to that symbol which will allow you to add OpenVMS specific hacks to the
programs. This does not always work, because when the CC/GCC wrapper
program gets too complex of a command, it can append it's own
/FIRST_INCLUDE qualifier.
In the vms_inc_first.h file, you can put such things as:
#define _POSIX_EXIT 1
#define _USE_STD_STAT 1 /* V8.2 or later */
#define _LARGEFILE
If you want to use the GNU getopt instead of the one in the CRTL:
/* Hide DECC getopt */
#include <unistd.h> /* Process the header for the prefixed symbols */
#define getopt gnu_getopt
#define optarg gnu_optarg
#define optopt gnu_optopt
#define optind gnu_optind
#define opterr gnu_opterr
#include <string.h> /* Missing from some gnu getopt.c */
Unless a UNIX program was written to specifically use OpenVMS exit
codes, the _POSIX_EXIT macro should probably be defined. Bash and some
newer versions of Perl need this in order to properly interpret the
non-zero exit codes of spawned processes.
Any program that actually uses "st_ino" values will either need OpenVMS
specific modifications for before V8.2 or for V8.2 and later will need
the _USE_STD_STAT. _USE_STD_STAT also will set _LARGEFILE. These
macros need to be defined before any standard headers are included.
If the project needs the alloca() function, then in the vms_inc_first.h
the following is needed for Configure and the program to find it.
#include <builtins.h>
#define alloca(__x) __alloca(__x)
GCC typically ignores this warning, so unless it is suppressed, it can
make the builds quite noisy.
#pragma message disable ptrmismatch1
And the Configure step may need a different first include header file
than the build step.
If you do not have C++ installed on your system, A configure script may
be fooled by the C++/G++/CXX programs on your system and insist on
trying to use them. In this case, you may need to rename those programs
or install the C++ compiler.
While this is not a complete answer, hopefully this will help in getting
some things ported.
-John
malm...@dskwld.zko.hp.compaq.dec
Personal Opinion Only
Dave Froble
In all the software I write, included are command files for compiling
and linking. Use of logicals for source code, object files and
libraries, executables makes it rather easy to re-build applications.
As for changes, when you change the source, if command file chenges are
required, you do them as part of the modification. Basically, building
the application is part of the application.
I don't see the difficulty in doing the same for C code.
Me, I'd rather be in charge of what goes into an application, not some
utility.
VAXman-
What's wrong with that Larry?
if ( it_compiles && it_links) it_ships;
Pretty commonplace unix software vendor stratagem and a corporate
policy at the Redmond Academy of teenage Software Neophytes Emit-
ting Substandard Technology.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)COM
"Well my son, life is like a beanstalk, isn't it?"
John Santos
> JF Mezei wrote:
>
>> Dave Froble wrote:
>>
>>> Not having ever seen such a utility, I cannot discuss it in detail.
>>> However, days? weeks? Cannot comprehend. Is this stuff all bloatware?
>>
>>
>>
>> If you have 500 source code modules, equal amount of includes with about
>> 20 that need to be created on-site based on your software configuration,
>> then yes, the make utility is needed.
>>
>> It isn't enough to CC *.C in that directory. Some modules need to have
>> special CC commands, others don't. And not everytrhing is necessarily
>> linked as a single .EXE. Maybe you are creting 15 .EXEs.
>>
>> Without the MAKE utility, you are stuck trying to interpret the unix
>> makefiles and create your own makefile (either .COM or other). And this
>> means that with every new version of that software, you need to go
>> through the work again.
>
>
> In all the software I write, included are command files for compiling
> and linking. Use of logicals for source code, object files and
> libraries, executables makes it rather easy to re-build applications. As
> for changes, when you change the source, if command file chenges are
> required, you do them as part of the modification. Basically, building
> the application is part of the application.
>
> I don't see the difficulty in doing the same for C code.
>
No problem, if you are the creator/maintainer of the code...
> Me, I'd rather be in charge of what goes into an application, not some
> utility.
But you aren't! :-(
The situation is you are trying to port some chunk of Unix-based code
to VMS. It is a moving target. (All non-dead code is constantly
changing...)
So you make a .COM that correctly builds version 2.11.2 (the current
version when you started.) But by the time you finish, version 2.12.4
is current, with lots of source changes, new modules, things get moved
around, etc.
With the "Make a .COM that builds everything" approach, by the time
you get this done (basically starting from scratch), it is out-of-date
again, and the source tree has forked. Version 2.12.5 fixes some tiny
but important security bug, and V3.1.3 is the main development stream
and has had important stuff re-written from scratch. (But is still
regarded as Beta-test quality.)
This is why I pity the Mozilla and Apache and Java people at HP, and
try not to get on their cases too much.
A much better approach, if you can get it to stick, is to get a build
environment on VMS that closely resembles the "standard" Unix
environment and get the VMS-specific source changes folded into the
common source. At least then, there is some chance things won't get
broken by accident, and the developers will at least know "here there
be VMS dragons", making it easier to port. Also, there may be a working
test suite, so you can make sure newer versions haven't broken anything.
The makefile and config stuff is very important to this process.
Remember, we *WANT* unix software (and current versions thereof) to
be available on VMS. Everything from little nifty utilities to convert
MS .DOC files to postscript (so you can print something someone mails
you) to Samba to Openoffice...
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Dave Froble
Ok John. Understood. I don't do much porting so I don't really see
such problems. Guess I should get out more, huh?
Ton van der Zwet
John,
We couldn't agree with you more! A few years we are trying to convince
people that the only possible way to port (open source) software is
through accepted (open) standards. In the case of open source software
this means in most cases the "standard" Unix/Linux environment.
To illustrate your point about keeping up with the latest and greatest
versions of software, the case we know best: OpenOffice... (a snippet
from an earlier mail, "you" in this mail was b...@instantwhip.com)
"To give you some idea of the size of the project:
- some 296 filetypes are in the bare source tree (everything counted)
- more than 9.000.000 lines of source code in the mayor languages (c++,
c, java)
Indirect you can help by improving the unix portability features. We
depend on good, stable, current version of gnv tooling to keep up with
the very fast moving OpenOffice development (every two weeks a new
milestone/release!!)
Or you can coordinate (a part of) the project.
Enough work to do on those long, dark winter evenings! ;-)
By the way, we are hobbyists..."
Ton van der Zwet,
member of the OpenOffice on OpenVMS porting team.
Martin Borgman
you're missing one of the most important options in "UNIX" porting. The
CRTL feature switches. With these feature switches you can change the
CRTL's behavior to a more "UNIX" like behavior.
And since you mention getopt, yes you can change getopts behavior to be
case sensitive. The way "UNIX" programs expect it to be.
Just look at the GNV sources and particularly at vms_crtl_init.c.
For a short introduction of how this works, please read the porting
guide at <http://www.oooovms.dyndns.org/reference/>.
Martin Borgman,
OpenOffice.org On OpenVMS porting group.
<http://www.oooovms.dyndns.org/>
S7Solutions
This is Manju from S7 [s7solutions.com]. We are the cross-platform
migration & porting experts with over 7 years of migration experience
onto various operating systems such as windows, UNIX & Linux. We have
ported over several millions of lines of code for big names like
Lucent, Marconi, Texas Instruments, Agile, Actel, Novell, Checkpoint,
Portwise, Bristol to name a few. If you think our developers can
contribute to the opensource I will definately encourage them to do so
during their free time and with Christmas around I am sure I can find
many with free time. Please do let me know any existing porting
projects and also how to contribute to the same.
Looking forward for your response
Thanks & Best Regards
Manju
*** CUSTOMER comes FIRST, come what may ********
Manjunath M
S7 Software Solutions Pvt. Ltd.
#83 Railway Parallel Road, Kumara Park West
Bangalore - 560020, India
Telephone: +91-80-51526777
Fax: +91-80-2334135
2936 173rd CT NE
Redmond, WA 98052, USA
Telephone: (425) 867 1457
Fax: (425) 883 2597
Toll Free: 1-888-224-6174
Yahoo messenger ID: s7softwaresolutions
MSN messenger ID: manj...@hotmail.com
Skype ID: s7softwaresolutions
"Redefining cross-platform porting & migration"
************************************************
Tom Linden
John E. Malmberg
> Hi John,
>
> you're missing one of the most important options in "UNIX" porting. The
> CRTL feature switches. With these feature switches you can change the
> CRTL's behavior to a more "UNIX" like behavior.
I was focusing mainly on what it takes to get through or around the
Configure step. To discuss every possible thing would be a very long post.
> And since you mention getopt, yes you can change getopts behavior to be
> case sensitive. The way "UNIX" programs expect it to be.
Actually the reason that I would have to use the GNU getopts behavior is
to get the long parameter name handling.
> Just look at the GNV sources and particularly at vms_crtl_init.c.
I am very familiar with some of the GNV sources, and have several
changes in the queue to be tested and integrated by the current HP
internal group that is responsible for the kit.
> For a short introduction of how this works, please read the porting
> guide at <http://www.oooovms.dyndns.org/reference/>.
For: http://www.oooovms.dyndns.org/reference/guide_19-jul-2005.pdf :
Page 30, discussion on fork().
If a program has a MS-DOS/Microsoft Windows variant, instead of fork, it
will use run-time library calls of spawnXX() with the "XX" being
replaced with characters that indicate how the arguments are passed.
I have not tested this, but it appears that this might be able to be
implemented with either a static procedure or a macro using vfork() and
the corresponding execXX() functions, which means less modifications to
the original source.
For Page 35, the example of M4. According to my build notes, the
current version of M4 is 1.4.3 and it has a good enough version of
config.guess so that the --build option is not needed. I did use:
bash$ export GNV_DISABLE_DCL_FALLBACK=1
bash$ ./configure --prefix=/usr --exec-prefix=/usr
I also set up SYS$POSIX root as a search list so that I could even run
the install step.
$! Hack so make install will work for non privileged users
$!---------------------------------------------------------
$define new_gnu DSKWLD$DKA100:[project_root.gnu.]/job/trans=conc
$save_gnu = f$trnlnm("GNU","LNM$SYSTEM_TABLE");
$define old_gnu 'save_gnu'/job/trans=conc
$define gnu new_gnu:,old_gnu:/job
$create/dir new_gnu:[bin]/prot=o:rwed
$create/dir new_gnu:[usr.bin]/prot=o:rwed
$create/dir new_gnu:[usr.include]/prot=o:rwed
$create/dir new_gnu:[usr.lib]/prot=o:rwed
$create/dir new_gnu:[usr.local]/prot=o:rwed
$create/dir new_gnu:[usr.share]/prot=o:rwed
$define sys$posix_root new_gnu,old_gnu/job
This was before I modified the [.wrapper]cc.c file to be a little more
friendly to both VMS and UNIX scripts. I am testing a GNV_CC_*
environment to auto-magically select a first include file based on the
module name.
$ type lcl_root:setup_m4_build.com
$cc :== CC/FIRST_INCLUDE=PRJ_ROOT:[M4-1^.4^.3]M4_VMS_1INC.H
$define DECC$ACL_ACCESS_CHECK ENABLE
$define DECC$ALLOW_REMOVE_OPEN_FILES ENABLE
[end-of-file]
$ type lcl_root:[m4-1^.4^.3]M4_VMS_1INC.H
/* missing include in getopt.c */
#include <string.h>
/* Hide DECC getopt */
#include <unistd.h>
#define getopt gnu_getopt
#define optarg gnu_optarg
#define optopt gnu_optopt
#define optind gnu_optind
#define opterr gnu_opterr
/* Missing include of stdlib.h in obstack.c */
/* If we include stdlib.h, it breaks configure */
/* because the temporary c files created by */
/* configure have prototypes that conflict with */
/* the built in ANSI prototyped headers */
void abort(void);
[end-of-file]
The write locked source is on src_root: and the build directory is on
lcl_root: with prj_root being a search list of lcl_root:,src_root:. And
I set my default to be prj_root:[m4-1^.4^.3] for the build.
I did not link in a lib$initialize program on the build that I did, I
was depending on the DECC$ feature logicals.
With the version of the CC wrapper that I am currently testing, I should
be able to add a suitable lib$initialize section in with out modifying
the build scripts.
For http://www.oooovms.dyndns.org/reference/ht/ :
I expect item #2 to no longer be needed with a future release of the GNV
kit.
Item #3 means that the project now has an out of date config.guess file,
and it is time for the maintainers of the mainstream of the project to
get a newer one, which is needed for both OpenVMS support and other
platforms.
-John
wb8...@qsl.network
malm...@dskwld.zko.hp.compaq.dec
Personal Opinion Only
Martin Borgman
Thanks you for your comments.
John E. Malmberg wrote:
> Martin Borgman wrote:
>> Hi John,
>>
>> you're missing one of the most important options in "UNIX" porting.
>> The CRTL feature switches. With these feature switches you can change
>> the CRTL's behavior to a more "UNIX" like behavior.
>
> I was focusing mainly on what it takes to get through or around the
> Configure step. To discuss every possible thing would be a very long post.
Indeed it would be:)
>
>> And since you mention getopt, yes you can change getopts behavior to
>> be case sensitive. The way "UNIX" programs expect it to be.
>
> Actually the reason that I would have to use the GNU getopts behavior is
> to get the long parameter name handling.
Your right, The CRTL implements the X/Open version of getopt and not the
GNU enhances one.
>
>> Just look at the GNV sources and particularly at vms_crtl_init.c.
>
> I am very familiar with some of the GNV sources, and have several
> changes in the queue to be tested and integrated by the current HP
> internal group that is responsible for the kit.
>
>> For a short introduction of how this works, please read the porting
>> guide at <http://www.oooovms.dyndns.org/reference/>.
>
> For: http://www.oooovms.dyndns.org/reference/guide_19-jul-2005.pdf :
>
> Page 30, discussion on fork().
>
> If a program has a MS-DOS/Microsoft Windows variant, instead of fork, it
> will use run-time library calls of spawnXX() with the "XX" being
> replaced with characters that indicate how the arguments are passed.
>
> I have not tested this, but it appears that this might be able to be
> implemented with either a static procedure or a macro using vfork() and
> the corresponding execXX() functions, which means less modifications to
> the original source.
To be perfectly honest, most of the stuff I port is UNIX open source
stuff. And I did not come across any spawnXX() calls. But I think your
assessment of the spawnXX() calls is right.
When I have some source code with a spawnXX() call, I can test your
thesis. Do you have something?
>
> For Page 35, the example of M4. According to my build notes, the
> current version of M4 is 1.4.3 and it has a good enough version of
> config.guess so that the --build option is not needed. I did use:
You right, M4 builds without the --build option. But Brad McCusker and
Steve Pitcher thought it was a good idea to add this to our examples.
>
> bash$ export GNV_DISABLE_DCL_FALLBACK=1
> bash$ ./configure --prefix=/usr --exec-prefix=/usr
>
> I also set up SYS$POSIX root as a search list so that I could even run
> the install step.
Are you using the simlink kit?
What version of GNV are you using?
>
> $! Hack so make install will work for non privileged users
> $!---------------------------------------------------------
> $define new_gnu DSKWLD$DKA100:[project_root.gnu.]/job/trans=conc
> $save_gnu = f$trnlnm("GNU","LNM$SYSTEM_TABLE");
> $define old_gnu 'save_gnu'/job/trans=conc
> $define gnu new_gnu:,old_gnu:/job
> $create/dir new_gnu:[bin]/prot=o:rwed
> $create/dir new_gnu:[usr.bin]/prot=o:rwed
> $create/dir new_gnu:[usr.include]/prot=o:rwed
> $create/dir new_gnu:[usr.lib]/prot=o:rwed
> $create/dir new_gnu:[usr.local]/prot=o:rwed
> $create/dir new_gnu:[usr.share]/prot=o:rwed
> $define sys$posix_root new_gnu,old_gnu/job
>
>
> This was before I modified the [.wrapper]cc.c file to be a little more
> friendly to both VMS and UNIX scripts. I am testing a GNV_CC_*
> environment to auto-magically select a first include file based on the
> module name.
>
This is a very good idea, I would like to add this to the porting guide.
> $ type lcl_root:setup_m4_build.com
> $cc :== CC/FIRST_INCLUDE=PRJ_ROOT:[M4-1^.4^.3]M4_VMS_1INC.H
> $define DECC$ACL_ACCESS_CHECK ENABLE
> $define DECC$ALLOW_REMOVE_OPEN_FILES ENABLE
> [end-of-file]
>
> $ type lcl_root:[m4-1^.4^.3]M4_VMS_1INC.H
> /* missing include in getopt.c */
> #include <string.h>
>
> /* Hide DECC getopt */
> #include <unistd.h>
> #define getopt gnu_getopt
> #define optarg gnu_optarg
> #define optopt gnu_optopt
> #define optind gnu_optind
> #define opterr gnu_opterr
>
> /* Missing include of stdlib.h in obstack.c */
> /* If we include stdlib.h, it breaks configure */
> /* because the temporary c files created by */
> /* configure have prototypes that conflict with */
> /* the built in ANSI prototyped headers */
> void abort(void);
> [end-of-file]
>
I have the very bad habit of correcting something that is wrong in the
first place. I would include string.h in getopt.c and I would include
stdlib.c in obstack.c.
> The write locked source is on src_root: and the build directory is on
> lcl_root: with prj_root being a search list of lcl_root:,src_root:. And
> I set my default to be prj_root:[m4-1^.4^.3] for the build.
>
> I did not link in a lib$initialize program on the build that I did, I
> was depending on the DECC$ feature logicals.
Yes, this works when you don't use the CRTL command line parsing functions.
>
> With the version of the CC wrapper that I am currently testing, I should
> be able to add a suitable lib$initialize section in with out modifying
> the build scripts.
There already is something in the gcc wrapper, but when I tested this,
there appeared to be something missing. This was quite some time ago though.
>
>
> For http://www.oooovms.dyndns.org/reference/ht/ :
>
> I expect item #2 to no longer be needed with a future release of the GNV
> kit.
So you are finally updating the pipe code in bash. Or will there be a
completely new version of bash?
>
> Item #3 means that the project now has an out of date config.guess file,
> and it is time for the maintainers of the mainstream of the project to
> get a newer one, which is needed for both OpenVMS support and other
> platforms.
Yes, we should change that text. When we discussed this with Steve
Pitcher a long time ago, we intended to provide a new configure.guess
(provided by Steve). This unfortunately never happened.
>
>
> -John
> wb8...@qsl.network
> malm...@dskwld.zko.hp.compaq.dec
> Personal Opinion Only
Were you aware of this porting guide?
Are you interested in contributing to this guide?
Regards,
John E. Malmberg
> John,
>
> Thanks you for your comments.
>
> John E. Malmberg wrote:
>
>> Page 30, discussion on fork().
>>
>> If a program has a MS-DOS/Microsoft Windows variant, instead of fork,
>> it will use run-time library calls of spawnXX() with the "XX" being
>> replaced with characters that indicate how the arguments are passed.
>>
>> I have not tested this, but it appears that this might be able to be
>> implemented with either a static procedure or a macro using vfork()
>> and the corresponding execXX() functions, which means less
>> modifications to the original source.
> To be perfectly honest, most of the stuff I port is UNIX open source
> stuff. And I did not come across any spawnXX() calls. But I think your
> assessment of the spawnXX() calls is right.
> When I have some source code with a spawnXX() call, I can test your
> thesis. Do you have something?
I saw this in the Open Office Source code a few years back, specifically
in the dmake program.
> Are you using the simlink kit?
Only on some test systems at work.
> What version of GNV are you using?
At work, I am using 1.06-11 with my patches.
[Code to create a search list for GNV files edited out.]
> This is a very good idea, I would like to add this to the porting guide.
Feel free to.
> I have the very bad habit of correcting something that is wrong in the
> first place. I would include string.h in getopt.c and I would include
> stdlib.c in obstack.c.
Can you get the maintainers of M4 to put the fixes in the next release?
Otherwise you end up making the same edits over and over again.
Right now, M4 is not on a critical path for what I need to get done.
>> I did not link in a lib$initialize program on the build that I did, I
>> was depending on the DECC$ feature logicals.
>
> Yes, this works when you don't use the CRTL command line parsing functions.
As long as you set the DECC$ logicals before the main() program is
called the command line parsing options work.
Currently I am using a modified version of Perl that uses those logicals
to change to a mode that is more compatible with Bash. I am slowly
getting those changes inserted into the main Perl version.
> There already is something in the gcc wrapper, but when I tested this,
> there appeared to be something missing. This was quite some time ago
> though.
In one of the projects I am working on, I have had to enhance the CC
wrapper every few days in one way or another to continue on it.
> So you are finally updating the pipe code in bash. Or will there be a
> completely new version of bash?
Just an update to the version in GNV, it was needed as part of other
tasks that I am doing for work.
> Were you aware of this porting guide?
No.
> Are you interested in contributing to this guide?
If I have time.
I am noticing that there seem to be several open source projects like
GTK and such that are needed for multiple projects, and a number of
smaller ones.
It takes a lot of time to participate in the mailing lists or other
forums for those projects once an OpenVMS port is done, to follow up and
keep the project buildable on VMS.
Martin Borgman
> Martin Borgman wrote:
>> John,
>>
>> Thanks you for your comments.
>>
>> John E. Malmberg wrote:
>>
>>> Page 30, discussion on fork().
>>>
>>> If a program has a MS-DOS/Microsoft Windows variant, instead of fork,
>>> it will use run-time library calls of spawnXX() with the "XX" being
>>> replaced with characters that indicate how the arguments are passed.
>>>
>>> I have not tested this, but it appears that this might be able to be
>>> implemented with either a static procedure or a macro using vfork()
>>> and the corresponding execXX() functions, which means less
>>> modifications to the original source.
>
>> To be perfectly honest, most of the stuff I port is UNIX open source
>> stuff. And I did not come across any spawnXX() calls. But I think your
>> assessment of the spawnXX() calls is right.
>> When I have some source code with a spawnXX() call, I can test your
>> thesis. Do you have something?
>
> I saw this in the Open Office Source code a few years back, specifically
> in the dmake program.
We intend to use the UNIX version of dmake. The UNIX version uses fork().
>
>> Are you using the simlink kit?
>
> Only on some test systems at work.
>
>> What version of GNV are you using?
>
> At work, I am using 1.06-11 with my patches.
I primarily use 1.06-2 on Alpha, this was the last version that worked
for me.
>
> [Code to create a search list for GNV files edited out.]
>> This is a very good idea, I would like to add this to the porting guide.
>
> Feel free to.
>
>> I have the very bad habit of correcting something that is wrong in the
>> first place. I would include string.h in getopt.c and I would include
>> stdlib.c in obstack.c.
>
> Can you get the maintainers of M4 to put the fixes in the next release?
> Otherwise you end up making the same edits over and over again.
>
some time ago I tried to get some fixes into cvs. They never answered my
email. Ill try again with M4. I can check the changes on my OSX machine
and on a ubuntu machine.
>
> Right now, M4 is not on a critical path for what I need to get done.
>
We need M4 for the standard GNU build tools.
>
>>> I did not link in a lib$initialize program on the build that I did, I
>>> was depending on the DECC$ feature logicals.
>>
>> Yes, this works when you don't use the CRTL command line parsing
>> functions.
>
> As long as you set the DECC$ logicals before the main() program is
> called the command line parsing options work.
Last time I checked the manuals stated otherwise. This would be a great
improvement.
>
> Currently I am using a modified version of Perl that uses those logicals
> to change to a mode that is more compatible with Bash. I am slowly
> getting those changes inserted into the main Perl version.
>
Great.
>> There already is something in the gcc wrapper, but when I tested this,
>> there appeared to be something missing. This was quite some time ago
>> though.
>
> In one of the projects I am working on, I have had to enhance the CC
> wrapper every few days in one way or another to continue on it.
>
One of the problems with the gcc wrapper is that it emulates a rather
old version of gcc. A more gcc v.3 compatible version would help us all.
>> So you are finally updating the pipe code in bash. Or will there be a
>> completely new version of bash?
>
> Just an update to the version in GNV, it was needed as part of other
> tasks that I am doing for work.
Again this is a great improvement for many porters out there.
>
>> Were you aware of this porting guide?
>
> No.
>
>> Are you interested in contributing to this guide?
>
> If I have time.
>
> I am noticing that there seem to be several open source projects like
> GTK and such that are needed for multiple projects, and a number of
> smaller ones.
>
> It takes a lot of time to participate in the mailing lists or other
> forums for those projects once an OpenVMS port is done, to follow up and
> keep the project buildable on VMS.
>
I understand, this is a problem for all of us.
One great way to help would be to tell others about it and let them send
us comments improvements or even new chapters.
> -John
> wb8...@qsl.network
> malm...@dskwld.zko.hp.compaq.dec
> Personal Opinion Only
--
Martin Borgman,
OpenOffice.org On OpenVMS porting group