From file: coreutils_release_note_start.com This is a fresh port of Coreutils 8.21 with input from the many VMS OpenSource developers. Much of this is from lessons learned from the Bash 4.2.45 port. Note: I am a hobbyist and am not providing any support or any commitment to supply bug fixes or future releases. This code is as-is with no warrantees. The testing of this port of Coreutils involved some spot testing of the various utilities, particularly the rm and mv utilities which had visible bugs in GNV. At this time, A VAX build has not been attempted and would need some work. Special installation notes: * Please see https://sourceforge.net/p/gnv/wiki/InstallingGNVPackages/ for the latest information on installing GNV related PCSI kits. * We are updating and replacing GNV one kit at a time and transitioning GNV to be a set of kits that the GNV package will install. During this transition some extra issues will need to be handled during installs and upgrades. * Due to the way that PCSI identifies packages, if you install a package from one producer and then want to upgrade it from another producer, you will probably need to uninstall the previous package first. Some of these packages were previously created with different producer prefixes. We are standardizing on VMSPORTS and GNV as the branding prefixes. GNV will be for packages that are part of the GNV product suite, and VMSPORTS will be for most other packages. This uninstall can cause warning messages about dependencies. If you are transitioning to an upwardly compatible package, you can ignore those warnings. * This package should be installed to the same volume as GNV is installed. If you uninstall or upgrade GNV or install a GNV from before the transition is complete, you will need to reinstall all other packages that install to the same GNV directory tree. This is because at least some of the existing GNV installation procedures have bugs in them were instead of just deleting the files that were installed, they delete all files in the GNV directory tree. * Because this is a transition, this package is replacing files from the old GNV packages. This is a necessary issue to allow incremental improvement as we can not replace the GNV package until we get all the component packages done. * The GNV 2.x through at least the 3.0.1 kits make an unusual change to the disk directory structure where they are installed where they use the [vms$common.gnv] as a mount point and mount the posix root on it. This is a bug because it causes many problems and does not offer any advantages. One of the problems is that it causes problems with other PCSI installs and uninstalls to that directory. This bug can be manually repaired such as has been done on on encompasserve.org as documented in PORTING_TO_VMS notes conference. At this time, we do not have a scripted repair to this bug, and it may not be possible to fully script a repair because this bug can cause the POSIX root and [vms$common.gnv] to have different contents when they should be the same directory, and it will take a manual inspection to select which files go where. * Because of the directory change bug, the gnv$startup.com in the GNV kit must be run when the system boots up or the [vms$common.gnv] directory will appear to be empty. If a PCSI kit like this one is installed when the GNV startup has not been run, it will create a new directory tree under [vms$common.gnv] that will not be visible to the posix root. If you uninstall this PCSI kit before running the gnv$startup.com procedure then you can install it after running the gnv$startup.com procedure. If you have run the gnv$startup.com procedure after the install, then you have a mess, and you will need to use the GNV umnt to un-mount the [vms$common.gnv] directory before the uninstall of this kit will work. An analyze/disk/repair step on the installation disk should be done after installation to collect files left over from incomplete deletions into the SYSLOST directory. This step should be done on a "quiet" system per HP recomendations. Bugs can be logged at the tracker with https://sourceforge.net/projects/gnv/. There is no guarantee that bugs will be fixed for a hobbyist build. VMS specific port information: The logical name GNV$GNU is used to find the simulated posix root and defines the logical name SYS$POSIX_ROOT in the process table in user mode for child processes if needed. This is to comply with VMS logical name conventions. The logical name BIN is also set in the process table in user mode to be GNV$GNU:[BIN] if it is not already set. The following DECC$Feature settings are in in effect for Coreutils by default: DECC$ACL_ACCESS_CHECK enabled. DECC$ALLOW_REMOVE_OPEN_FILES enabled. DECC$ARGV_PARSE_STYLE enabled. DECC$EFS_CASE_PRESERVE enabled. DECC$EFS_CHARSET enabled. DECC$EFS_FILE_TIMESTAMPS enabled. DECC$ENABLE_GETENV_CACHE enabled. DECC$EXEC_FILEATTR_INHERITANCE set to 2. DECC$FILE_PERMISSION_UNIX enabled. DECC$FILE_SHARING enabled. DECC$FILE_OWNER_UNIX enabled. DECC$FILENAME_UNIX_NO_VERSION enabled. DECC$FILENAME_UNIX_ONLY enabled. DECC$GLOB_UNIX_STYLE enabled. DECC$POSIX_SEEK_STREAM_FILE enabled. DECC$READDIR_DROPDOTNOTYPE enabled. DECC$RENAME_NO_INHERIT enabled. DECC$STDIO_CTX_EOL enabled. DECC$STRTOL_ERANGE enabled. DECC$UNIX_PATH_BEFORE_LOGNAME enabled. While more strict UNIX compatibility feature settings can be applied by users by setting feature logical names, these settings are all the Bash and most ported programs need. Coreutils currently uses the same control characters as VMS. Control-Z is EOF. It will need to be a future enhancement to have the control characters set by programs so that they can be set to match UNIX where possible by the terminal driver. This port of Coreutils uses the VMS CRTL to handle the Unix format pathnames and as such is dependent on them. It is a known issue that directories with a Unix name "file.dir/" and some symbolic links are not handled correctly. This is a combination of problems with RMS and CRTL. The RMS portion is fixed with the VMS84?_RMS-V0300 ECO kit. I am not aware of a CRTL kit that fixes the issues. Workarounds have been implemented for the cases that have been observed in for running configure scripts. These are not complete work arounds, so there still may be corner cases that fail. This kit is designed to be used with the GNV Bash 4.2.45 or later kit. Fixes and enhancements: * No logical names required for proper Coreutils operations other than GNV$GNU for locating the simulated "/". The older GNV programs may still need the logical names until they get the same fixes. Those additional logical names should be set in GNV$GNU:[lib]gnv_setup.com instead of in the system startup. * GNV$GNU is used to find the posix root and locally sets SYS$POSIX_ROOT for child processes if needed. This is to comply with VMS logical name conventions. The logical name BIN is also set locally to be GNV$GNU:[BIN] if it is not already set. * New MMK based build procedure that uses a search list. MMS does not appear to work properly for ODS-5 filenames using lowercase names. * config.h now generated at part of the build from a template. The supplied GNV$COREUTILS_STARTUP.COM procedure is provided in [VMS$COMMON.SYS$STARTUP] can be put in your VMS startup procedure to install selected images as known because they need privileges. It is recommended that the GNV$STARTUP.COM procedure be run first, followed by the GNV$BASH_STARTUP.COM procedure before the GNV$COREUTILS_STARTUP.COM is executed. The gnv$users.exe, and gnv$who.exe images are installed with WORLD privilege to get process information, and gnv$pinky.exe is installed with WORLD and READALL to get process information and read the SYSUAF information. The names of the coreutils images have been prefixed with GNV$ to prevent possible naming conflicts with other programs that are on the system. The GNV$ prefix has been registered with HP for this purpose. OpenVMS specific building and kitting instructions are after the standard bash readme file below. The source kits contains files for building Coreutils using MMK. MMK 4.0 was used for this build on Alpha and Itanium Itanium. Acknowledgements: This port was done by John Malmberg using information from the Bash 4.2.45 port. Open Bugs: Tiket # Title -------- --------------------------------------------------------------- 50 CRTL bug in lstat causes bugs in ls and rm commands A hack has been applied to make this issue less visible. It is expected to be fixed in a future HP CRTL ECO for OpenVMS 8.4. 46 Can't create and remove a directory named a.dir A hack has been applied to make this issue less visible. 36 ls not handling directories correctly A hack has been applied to make this issue less visible. Closed bugs: Ticket # Title -------- --------------------------------------------------------------- 69 mv fails with source/destinations on different volumes. 56 rm -rf not deleting directory trees. There may have also been other bugs in the GNV ports of coreutils for OpenVMS that were not officially recorded but have now been fixed as a result of resolving the above listed bug reports. So, you are encouraged to try out this release and report anomolies on the GNV Bug Reporting page: https://sourceforge.net/p/gnv/bugs/?source=navbar Currently, the focus of the OpenVMS GNV porting team is to address bugs in the OpenVMS port of GNV components that pose immediate barriers to running configure and make scripts for Open Source Software packages targeting OpenVMS environments. The GNV development team is involved in an ongoing effort to identify and document the underlying technical causes for these current limitations and (if available) workarounds as well as developing code fixes to eliminate them. The VMS-Ports Source Forge project at https://sourceforge.net/p/vms-ports/tickets/ currently documents OpenVMS CRTL bugs and limitations with respect to porting Open Source Software using OpenVMS. The VMS-Ports Source Forge Project also contains examples of ported packages provided by volunteer contributors as well as documentation with recommendations on how to setup, modify and use the OpenVMS GNV environment for the purpose of porting Open Source software packages to OpenVMS. Browse to https://sourceforge.net/p/vms-ports/wiki/Home/ for more information. With the above statements in mind, there are a few known limitations of the Coreutils release. Though Corutils with Bash 4.2.45 successfully executes its own configure script, we are building using DCL using MMK and the supplied coreutils.mms description file. The assumption is that if you are building a core GNV component, that you do not already have a working GNV environment. What follows is the list of known behavioral differences/limitations between the OpenVMS port of Coreutils and that of typical UNIX/Linux environments. 1.) The stty utility is read-only. 2.) The date utility is read-only. 3.) The hostid utility returns the SCSSYSTEMID lower longword. 4.) The sync utility does nothing on OpenVMS. 5.) The nice utility does not appear to lower priorities. The OpenVMS CRTL manual for the nice() function does not document how to map the Unix priority changes to VMS priorities. 6.) As a result of missing support for certain C99 features in the OpenVMS CRTL, the following elements of format specifications for the printf utility are not supported: The format specifier flag: I (alternative locale digits for decimal integer conversions [i,d,u,f,g,G]) The length modifiers: hh (signed/unsigned char), j (intmax_t/uintmax_t), q (quadword), z (size_t/ssize_t), t (ptrdiff_t) %F (C99 uppercase IEEE NaN and infinity value strings for floating point double) The following date/time format specifications: %g (ISO 8601 week-based year expressed as two-digit year) %G (ISO 8601 week-based year expressed as four-digit century) %k (The blank padded two-digit hour [24-hour clock] as a decimal number [range 0 to 23] similar to %H) %l (The blank padded two-digit hour [12-hour clock] as a decimal number [range 1 to 12] similar to %I) %P (Lower case am/pm designator similar to %p) %s (The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 [UTC]) %z (The +hhmm or -hhmm numeric timezone [that is, the hour and minute offset from UTC]) %+ (The date and time in date(1) format [e.g. Sun Jul 7 17:56:05 EDT 2013]) 7.) The following utilities are not implemented because they are SELINUX specific. chcon, runcon 8.) The following utilities are not currently implemented on VMS. chroot This requires a lot more planning on how to implement. mkfifo No fifos currently on VMS. mknod No support on VMS and currently no effective way to emulate. nohup This requires a lot more planning on how to implement. stdbuf This requires a lot more planning on how to implement. These are the GNU core utilities. This package is the union of the GNU fileutils, sh-utils, and textutils packages. Most of these programs have significant advantages over their Unix counterparts, such as greater speed, additional options, and fewer arbitrary limits. The programs that can be built with this package are: [ arch base64 basename cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold groups head hostid hostname id install join kill link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami yes See the file NEWS for a list of major changes in the current release. If you obtained this file as part of a "git clone", then see the README-hacking file. If this file came to you as part of a tar archive, then see the file INSTALL for compilation and installation instructions. These programs are intended to conform to POSIX (with BSD and other extensions), like the rest of the GNU system. By default they conform to older POSIX (1003.2-1992), and therefore support obsolete usages like "head -10" and "chown owner.group file". This default is overridden at build-time by the value of 's _POSIX2_VERSION macro, and this in turn can be overridden at runtime as described in the documentation under "Standards conformance". The ls, dir, and vdir commands are all separate executables instead of one program that checks argv[0] because people often rename these programs to things like gls, gnuls, l, etc. Renaming a program file shouldn't affect how it operates, so that people can get the behavior they want with whatever name they want. Special thanks to Paul Eggert, Brian Matthews, Bruce Evans, Karl Berry, Kaveh Ghazi, and François Pinard for help with debugging and porting these programs. Many thanks to all of the people who have taken the time to submit problem reports and fixes. All contributed changes are attributed in the commit logs. And thanks to the following people who have provided accounts for portability testing on many different types of systems: Bob Proulx, Christian Robert, François Pinard, Greg McGary, Harlan Stenn, Joel N. Weber, Mark D. Roth, Matt Schalit, Nelson H. F. Beebe, Réjean Payette, Sam Tardieu. Thanks to Michael Stone for inflicting test releases of this package on Debian's unstable distribution, and to all the kind folks who used that distribution and found and reported bugs. Note that each man page is now automatically generated from a template and from the corresponding --help usage message. Patches to the template files (man/*.x) are welcome. However, the authoritative documentation is in texinfo form in the doc directory. ***************************************** On Mac OS X 10.5.1 (Darwin 9.1), test failure ----------------------------------------- Mac OS X 10.5.1 (Darwin 9.1) provides only partial (and incompatible) ACL support, so although "./configure && make" succeeds, "make check" exposes numerous failures. The solution is to turn off ACL support manually via "./configure --disable-acl". For details, see . ***************************************** Test failure with NLS and gettext <= 0.17 ----------------------------------------- Due to a conflict between libintl.h and gnulib's new xprintf module, when you configure with NLS support, and with a gettext installation older than 0.17.1 (not yet released, at the time of this writing), then some tests fail, at least on NetBSD 1.6. To work around it in the mean time, you can configure with --disable-nls. For details, see . *********************** Pre-C99 build failure ----------------------- There is a new, implicit build requirement: To build the coreutils from source, you should have a C99-conforming compiler, due to the use of declarations after non-declaration statements in several files in src/. There is code in configure to find and, if possible, enable an appropriate compiler. However, if configure doesn't find a C99 compiler, it continues nonetheless, and your build will fail. If that happens, simply[*] apply the included patch using the following command, and then run make again: cd src && patch < c99-to-c89.diff [*] however, as of coreutils-7.1, the "c99-to-c89.diff" file is no longer maintained, so even if the patches still apply, the result will be an incomplete conversion. It's been 10 years. Get a decent compiler! ;-) *********************** HPUX 11.x build failure ----------------------- A known problem exists when compiling on HPUX on both hppa and ia64 in 64-bit mode (i.e. +DD64) on HP-UX 11.0, 11.11, and 11.23. This is not due to a bug in the package but instead due to a bug in the system header file which breaks things in 64-bit mode. The default compilation mode is 32-bit and the software compiles fine using the default mode. To build this software in 64-bit mode you will need to fix the system /usr/include/inttypes.h header file. After correcting that file the software also compiles fine in 64-bit mode. Here is one possible patch to correct the problem: --- /usr/include/inttypes.h.orig Thu May 30 01:00:00 1996 +++ /usr/include/inttypes.h Sun Mar 23 00:20:36 2003 @@ -489 +489 @@ -#ifndef __STDC_32_MODE__ +#ifndef __LP64__ ************************ OSF/1 4.0d build failure ------------------------ If you use /usr/bin/make on an OSF/1 4.0d system, it will fail due to the presence of the "[" target. That version of make appears to treat "[" as some syntax relating to locks. To work around that, the best solution is to use GNU make. Otherwise, simply remove all mention of "[$(EXEEXT)" from src/Makefile. ************************************************* "make check" failure on IRIX 6.5 and Solaris <= 9 ------------------------------------------------- Using the vendor make program to run "make check" fails on these two systems. If you want to run all of the tests there, use GNU make. ********************** Running tests as root: ---------------------- If you run the tests as root, note that a few of them create files and/or run programs as a non-root user, 'nobody' by default. If you want to use some other non-root username, specify it via the NON_ROOT_USERNAME environment variable. Depending on the permissions with which the working directories have been created, using 'nobody' may fail, because that user won't have the required read and write access to the build and test directories. I find that it is best to unpack and build as a non-privileged user, and then to run the following command as that user in order to run the privilege-requiring tests: sudo env PATH="$PATH" NON_ROOT_USERNAME=$USER make -k check-root If you can run the tests as root, please do so and report any problems. We get much less test coverage in that mode, and it's arguably more important that these tools work well when run by root than when run by less privileged users. *************** Reporting bugs: --------------- IMPORTANT: if you take the time to report a test failure, please be sure to include the output of running 'make check' in verbose mode for each failing test. For example, if the test that fails is tests/df/df-P.sh, then you would run this command: make check TESTS=tests/df/df-P.sh VERBOSE=yes SUBDIRS=. >> log 2>&1 For some tests, you can get even more detail by adding DEBUG=yes. Then include the contents of the file 'log' in your bug report. Send bug reports, questions, comments, etc. to bug-coreutils@gnu.org. If you would like to suggest a patch, see the files README-hacking and HACKING for tips. *************************************** There are many tests, but nowhere near as many as we need. Additions and corrections are very welcome. If you see a problem that you've already reported, feel free to re-report it -- it won't bother me to get a reminder. Besides, the more messages I get regarding a particular problem the sooner it'll be fixed -- usually. If you sent a complete patch and, after a couple weeks you haven't received any acknowledgement, please ping us. A complete patch includes a well-written ChangeLog entry, unified (diff -u format) diffs relative to the most recent test release (or, better, relative to the latest sources in the public repository), an explanation for why the patch is necessary or useful, and if at all possible, enough information to reproduce whatever problem prompted it. Plus, you'll earn lots of karma if you include a test case to exercise any bug(s) you fix. Here are instructions for checking out the latest development sources: http://savannah.gnu.org/git/?group=coreutils If your patch adds a new feature, please try to get some sort of consensus that it is a worthwhile change. One way to do that is to send mail to bug-coreutils@gnu.org including as much description and justification as you can. Based on the feedback that generates, you may be able to convince us that it's worth adding. WARNING: Now that we use the ./bootstrap script, you should not run autoreconf manually. Doing that will overwrite essential source files with older versions, which may make the package unbuildable or introduce subtle bugs. WARNING: If you modify files like configure.in, m4/*.m4, aclocal.m4, or any Makefile.am, then don't be surprised if what gets regenerated no longer works. To make things work, you'll have to be using appropriate versions of the tools listed in bootstrap.conf's buildreq string. All of these programs except 'test' recognize the '--version' option. When reporting bugs, please include in the subject line both the package name/version and the name of the program for which you found a problem. For general documentation on the coding and usage standards this distribution follows, see the GNU Coding Standards, http://www.gnu.org/prep/standards_toc.html. For any copyright year range specified as YYYY-ZZZZ in this package note that the range specifies every single year in that closed interval. Mail suggestions and bug reports for these programs to the address on the last line of --help output. ======================================================================== Copyright (C) 1998-2013 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the "GNU Free Documentation License" file as part of this distribution. GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS 0. Definitions. "This License" refers to version 3 of the GNU General Public License. "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. "The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations. To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work. A "covered work" means either the unmodified Program or a work based on the Program. To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. 1. Source Code. The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. The Corresponding Source for a work in source code form is that same work. 2. Basic Permissions. All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. 3. Protecting Users' Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date. b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to "keep intact all notices". c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so. A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. 6. Conveying Non-Source Forms. You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d. A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work. A "User Product" is either (1) a "consumer product", which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, "normally used" refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product. "Installation Information" for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made. If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM). The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network. Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying. 7. Additional Terms. "Additional permissions" are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions. When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission. Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or d) Limiting the use for publicity purposes of names of licensors or authors of the material; or e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors. All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying. If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms. Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way. 8. Termination. You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11). However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation. Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice. Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10. 9. Acceptance Not Required for Having Copies. You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so. 10. Automatic Licensing of Downstream Recipients. Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License. An "entity transaction" is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts. You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it. 11. Patents. A "contributor" is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's "contributor version". A contributor's "essential patent claims" are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, "control" includes the right to grant patent sublicenses in a manner consistent with the requirements of this License. Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version. In the following three paragraphs, a "patent license" is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To "grant" such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party. If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. "Knowingly relying" means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid. If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it. A patent license is "discriminatory" if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007. Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law. 12. No Surrender of Others' Freedom. If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program. 13. Use with the GNU Affero General Public License. Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such. 14. Revised Versions of this License. The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License "or any later version" applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version. 15. Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. 16. Limitation of Liability. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 17. Interpretation of Sections 15 and 16. If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. END OF TERMS AND CONDITIONS How to Apply These Terms to Your New Programs If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the "copyright" line and a pointer to where the full notice is found. Copyright (C) This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see . Also add information on how to contact you by electronic and paper mail. If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode: Copyright (C) This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'. This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details. The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an "about box". You should also get your employer (if you work as a programmer) or school, if any, to sign a "copyright disclaimer" for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see . The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read . From File: coreutils_build_steps.txt Copyright 2013, John Malmberg Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. Building COREUTILS on OpenVMS for use with GNV requires a current HP C compiler and MMK. The HP C 7.x compilers were used for building on Alpha and Itanium. At this time a VAX build has not been attempted. Building the man pages was done with Perl 5.14. MMK was obtained from https://github.com/endlesssoftware/mmk Several special things were done in this port of Coreutils to VMS to make it easier to keep it up to date with the Unix version. Note the GNV$ prefix is registered for the GNV project to prevent name collisions with other products and packages. This is a VMS convention. The files are stored with GNV_ instead of GNV$ most open source source code maintainers do not want to files with $ in their source repositories. The build procedure will copy the files to have the GNV$ names as needed. 1. The original GNU Coreutils source files are in their own directory tree which is never written to by the build process. This directory is kept up to date with the current official patches. See below about the how this is done with logical names. 2. Modifications to the original GNU Coreutils sources were avoided as much as possible. The prefered methods are to insert hacks in to a header file included by a generated config.h file, provide wrapper or replacement routines, and sometimes a /first_include header file as described below. 3. Where a source file had to be modified for the VMS port, instead of editing the file directly, a TPU editor script as defined below. While the script may occasionally need tweaking to accomodate a new official Coreutils patch, usually it will not. More on that below. 4. Most of the files that are normally generated by the GNU coreutils configure and makefile are generated by the VMS build procedure instead of being hard coded. 5. A file vms_eco_level.h is used to set the ECO of the package. The vms_eco_level.h needs to be set back to zero if the version or patch level of the GNU Unix source is changed. 6. Any VAX build is an experimental build that is not currently very useful and is not being tested. The use of the /first_include header files for selected modules is to provide replacement routines for ones either missing from the CRTL or ones that did not work the way that Coreutils required. The files used for a /first_include are named gnv_*.c_first in the GNV CVS repository. The build procedure will rename them to gnv$*.c_first before using them. This is for compatibility with GNV based builds, where the CC compiler will automatically use a gnv$*.c_first file if it is present. A feature of the HP CC compiler where it will ignore a non-existent directory in an #include directive is used to make sure that the VMS system header files are used instead of once provided with the ported product. Macros and static routines are used. A TPU script UNIX_C_TO_VMS_C.TPU provides a number of editor subroutines that are useful in patching files. A module specific TPU file can contain its own TPU commands, or it can call the editing routines. In most cases the Editing routines can be used to insert a patch. The source kits are provided in backup savesets inside of the PCSI install kit. Backup save sets are currently the only distribution medium that I can be sure is installed on a target VMS system that will correctly unpack files with extended character sets in them. You may need to adjust the ownership of the restored files for kits on Alpha/Itanium VMS versions 8.1 and earlier. On VAX, the filenames will be as seen on the VAX system, typically with non ODS-2 characters and case changes prefixed with $ characters. [gnv.common_src]coreutils_*_original_src.bck is the original source of the coreutils kit as provided by the GNV project. [gnv.vms_src]coreutils-*_vms_src.bck, if present, has the changed files that are used for building that are not yet in the coreutils source kits distributed by the GNU coreutils project. These backup savesets should be restored to different directory trees on an ODS-5 volume(s) which are referenced by concealed rooted logical names, unless on VAX, where either an NFS or ODS-2 volume can be used. SRC_ROOT: is for the source files common to all platforms. This can be a read only copy of the files from a change control repository. In my build environment, the SOURCE_ROOT:[gnu.coreutils] is the same directory as src_root:[coreutils]. VMS_ROOT: is for the files that were changed from the repository copy of SRC_ROOT: Note, you should create the VMS_ROOT: directory tree even if it is initially empty. This is where you should put edits if you are making changes. In my build environment, the source_root:[gnu_vms.coreutils] is a directory with the CVS checked out code and vms_root:[coreutils] is a copy with any local modifications. The command procedure compare_coreutils_source.com will report any differences in the source_root:[gnu_vms.coreutils] directory and the vms_root:[coreutils] directory. If the source_root: logical is not defined, it will translate the logical name src_root to do the effective of src_root:[coreutils.-.-.gnu_vms.coreutils] to find the VMS specific code CVS checkout based on where the checkout for the GNU source is expected to be. LCL_ROOT: is manually created to have the same base and sub-directories as SRC_ROOT: and VMS_ROOT: This is for the architecture specific binaries and other files created during the build. The logical name REF_ROOT: is defined to be a logical name that is a search list for VMS_ROOT:,SRC_ROOT: The logical name PRJ_ROOT: is defined to be a logical name that is a search list for LCL_ROOT:,REF_ROOT: The VMS_ROOT and LCL_ROOT directory trees can be created with commands similar to: $ create/dir lcl_root:[coreutils]/prot=w:re $ copy src_root:[coreutils...]*.dir - lcl_root:[coreutils...]/prot=(o:rwed,w:re) $ create/dir vms_root:[coreutils]/prot=w:re $ copy src_root:[coreutils...]*.dir - vms_root:[coreutils...]/prot=(o:rwed,w:re) One of the ways with to protect the source from being modified is to have the directories under src_root: owned by a user or resource where the build username only has read access to it. Note that if src_root: or vms_root: are NFS mounted disks, the step of backing up the source files will probably hang or fail. You need to copy the source files to VMS mounted disks and create logical names SRC_ROOT1 and VMS_ROOT1 to work around this to to reference local disks. Make sure src_root1:[000000] and vms_root1:[000000] exist and can be written to. The command procedure compare_coreutils_source can be used to check those directories and keep them up to date. @[.vms]compare_coreutils_source.com SRCBCK UPDATE This compares the reference GNU source with the backup staging directory for it and updates with any changes. @[.vms]compare_coreutils_source.com VMSBCK UPDATE This compares the VMS specific source with the backup staging directory for it and updates with any changes. Leave off "UPDATE" to just check without doing any changes. If you are not using NFS mounted disks and do not want to have a separate directory for staging the sources for backup make sure that src_root1: and vms_root1: do not exist. With these search lists set up and the properly, coreutils can be built by setting your default to PRJ_ROOT:[coreutils] and then issuing the command: $ @[.vms]build_vms.com This command procedure will do the steps below and will build a PCSI kit if the GNV_PCSI_PRODUCER and GNV_PCSI_PRODUCER_FULL_NAME, and STAGE_ROOT are defined. First it will build the binaries by using MMK utility. $ mmk/descrip=[.vms]coretuils.mms Note some messages may be present about libraries not being updated by actions. This is an issue where MMS and MMK are not handling the correct case of the module names, and at this time I have not found a way to work around it. To clean up after a build to start over, run the @clean_coreutils.com. Use the parameter "realclean" if you are going to run the configure script again. $ @[.vms]clean_coreutils.com realclean The man pages are built with a perl script called by the dcl script: $ @[.vms]build_coreutils_man_pages.com The files are installed into a NEW_GNU directory for staging by running the procedure stage_coreutils_install.com. This copies the binaries and creates alias links to them. $ @[.vms]stage_coreutils_install.com On the VAX platform, the staged files are needed for building the PCSI kit, as the VAX source was staged on an NFS volume, which encodes the filenames that have any upper case or special symbols in them. To remove the staged files, the procedure is run again with the parameter "REMOVE". This makes sure that the alias links are removed. Building a PCSI kit for an architecture takes the following steps after making sure that you have a working build environment. Note that it requires manually creating two logical names as described below. It is intentional that they be manually set. This is for branding the PCSI kit based on who is making the kit. 1. Make sure that you have a staging directory that can be referenced by the path STAGE_ROOT:[KIT] 2. Edit the file coreutils_release_note_start.txt or other text files to reflect any changes. 3. Define the logical name GNV_PCSI_PRODUCER to indicate who is making the distribution. For making updates to an existing open source kit you may need to keep the producer the same. 4. Define the logical name GNV_PCSI_PRODUCER_FULL_NAME to be your full name or full name of your company. 6. Edit the file PCSI_COREUTILS_FILE_LIST.TXT if there are new files added to the kit. These files should all be ODS-2 legal filenames and directories. A limitation of the PCSI kitting procedure is that when selecting files, it tends to ignore the directory structure and assumes that all files with the same name are the same file, so every file placed in the kit must have a unique name. Then a procedure needs to be added to the kit to create an alias link on install and remove the link on remove. Since at this time coreutils does not need this alias procedure, the steps to automatically build it are not included here. While newer versions of PCSI can support ODS-5 filenames, not all verions of PCSI on systems that have ODS-5 filenames do. So as a post install step, the PCSI kit built by these steps does a rename to the correct case. 7. Build the PCSI kit with @[.vms]pcsi_product_coreutils.com On VAX, the product command always prompts to the terminal for a confirmation. If there is another kit for this same version of coreutils, but for a different base platform or operating system version, the product command will prompt to the terminal to select which one to compress. The following message is normal: %PCSI-I-CANNOTVAL, cannot validate EAGLE$DQA0:[stage_root.][kit]GNV-AXPVMS-COREUTILS-V--1.PCSI;1 -PCSI-I-NOTSIGNED, product kit is not signed and therefore has no manifest file This will result in both compressed and uncompressed kits for the target platform. Good Luck.