From file: ld_tools_release_note_start.com This is tool to provide a wrapper around LD and the C/C++ compilers to translate the syntax from UNIX syntax to VMS syntax. The C/C++ compiler links are only installed if the compilers are installed on the system. If the compilers are installed after the this kit is installed, then run the GNV$GNU:[vms_bin]ld_tools_alias_setup.com 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 wrapper involved using it to build cPython 3.5 pre-release. 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 the LD_TOOLS images 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_REPORT_UNIX enabled. DECC$FILENAME_UNIX_NO_VERSION 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. These tools use 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. Usage Notes: This kit is designed to be used with the GNV Bash 4.2.47 or later kit. The LD tools are designed to be installed in the GNV$GNU directory tree and simulate the "ld" program. If the HP CC compiler is present, hard links for "cc" and "cpp" progams will be also created. If the HP CXX compiler is present the hard links for "cxx" and "c++" will be created. The "--help" option will show brief information for the specific program named used to invoke it. The "-v" option will list all the options, including depecated features. The intent of this tool is to allow running unmodified Unix build scripts on VMS. Because of differences in the VMS environment and Unix environments many source programs will not just compile and link on VMS. This tool has several enhancements that allow you to add helper files and scripts with out modifying the original build scripts. Some of them are controlled by Bash environment variables. If you set foreign commands for the VMS DCL CC, CXX, LINK, commands, they will be used by this tool. The tool will add qualifiers to those commands based on the UNIX options and other special options. If you have SET VERIFY active, the DCL commands used for the compile and link will be displayed on the terminal. This can cause problems with configure scripts. If your compiler supports /main=posix_exit, you should "export GNV_MAIN_POSIX_EXIT=1". If your compiler does not support this, if the ported program returns from main() without calling exit() the status will not be properly encoded. When issuing the CC, CXX, or LINK operations for file "foo.c", "foo.cc" or "foo.[exe]". The tool will look for a "gnv$foo_cc.com", "gnv$foo_cxx.com", or "gnv$foo_link.com" and run them before the operation. This will allow you to do things like running a patch script, or link an object library into a shared image. Generally you will want to set "export GNV_OPT_DIR=.". The GNV_OPT_DIR environment variable has two effects. It causes LD to look for "/GNV$.opt" to use when linking a file if that file exists. This will allow you to add shared images, objects and libraries for a link. By the default the LD tool will only issue a notice about any libraries mentioned in the command line that do not exist and continue to run. The second effect is that the CC/CXX compilers will add the equivalent of /first_include=/gnv$first_include.h if that file exists. The CC/CXX compilers will look for the file gnv$_first when compiling foo.c or foo.cc and use it as a /first_include if it is present. When that happens, the gnv$first_include.h will not be used. These first include files allow you to add additional routines and macros to the build. You can replace VMS CRTL routines by putting wrappers around them. The environment variables GNV_CC_QUALIFIERS, GNV_CXX_QUALIFIERS, GNV_CXXLINK_QUALIFIERS, and GNV_LINK_QUALIFIERS allow you to override the options specified by Unix. Helpful when the build script requests strict standard compliant, yet the source is not actually compliant with the standard. The environment variables GNV_CC_SET_COMMAND, GNV_CXX_SET_COMMAND can specify a single DCL command that will be run before the compiler. You can export GNV_LINK_LIB_OVER_SHARED=1 to cause the LD command to look for a GNV$LIB: logical name and if it exists will add it as a shared image, ignoring any lib.a or lib.olb files. Some examples: Use a "prebuild" command procedure to set up the DCL symbols and logical names for the compiler and linker. Most open source projects need the CC options: /names=(as_is,short)- /main=posix_exit- /float=IEEE/IEEE_MODE=DENORM_RESULTS Building on a search list usually requires the CC option: /nested=NONE. So for cPython 3.5, I set: (wrapped line warning) $ show sym cc CC == "CC/STANDARD=(RELAXED,ISOC94)/ACCEPT=(NOVAXC,RESTR,C99)/LIST /SHOW=(EXPAN,INCLU)/NAMES=(AS_IS,SHORT)/MAIN=POSIX_EXIT /FLOAT=IEEE/IEEE_MODE=DENORM_RESULTS/NESTED=NONE" The DECC$SYSTEM_INCLUDE and other logicals may also be needed. $show log decc$*include/proc "DECC$SYSTEM_INCLUDE" = "[.vms]" The configure tests are typically run with out header files present, and that means the VMS exit() behavior will be used. The configure tests need the posix_exit() instead. Other things may be need on a per-project basis, and if you are building extra libraries, you may have to put code there as stubs for the routines configure tests so that configure believes that the libraries already exist. The configure tests typically do not know how to find the shared images for the VMS versions of utilities. These are fixed up with the gnv$conftest.c_first and gnv$conftest.opt. If you have c++ code, you may need a gnv$conftest.cc_first to get the right results. $ type gnv$conftest.* LCL_ROOT:[cpython]gnv$conftest.c_first;1 void __posix_exit(int __status); #define exit(__p1) __posix_exit(__p1) /* Needed for stropts test */ #define u_short unsigned short #define u_char unsigned char #define u_long unsigned long LCL_ROOT:[cpython]gnv$conftest.opt;1 gnv$libzshr/share You will have to inspect the config.log and *config.h after running configure to verify the results. Contrary to the apparent goal, the tests in configure are not properly testing what the programmer is actually looking for, and many of the tests will always fail on any platform with backwards binary compatibility, like commercial operating systems. With other platforms, these configure failures may not be noticed. On VMS they will usually cause configure to try alternate options that are even less likely to be supported. Fixes and enhancements: * No logical names required for proper operations other than GNV$GNU for locating the simulated "/". * 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. * Previouse GNV kits had this tool named CC.EXE and then either copied or hard link to be other image names. This kit has the image named GNV$LD.EXE and hard links to the compiler wrapper images. This is becaues the LINK command will always be present. The compilers are optional. GNV ticket: https://sourceforge.net/p/gnv/bugs/47/ * Previous GNV kits created GCC/G++ links. This causes confusion for build tools since they expect tools with those names to behave identical to the GCC compiler family. These links will no longer be provided. GNV ticket: https://sourceforge.net/p/gnv/bugs/47/ * cc -pedantic was failing. https://sourceforge.net/p/gnv/bugs/35/ * --print-multiarch was failing. https://sourceforge.net/p/gnv/bugs/80/ * -x c++ not implemented. Anything other than "cxx" starting with "c" was treated as "c". "cxx" is not a documented gcc "-x" option. When using "-x c++", the link command also needs to be forced to be for a c++ object module file on VAX and Alpha. https://sourceforge.net/p/gnv/bugs/87/ * Handle .so files as shared images. https://sourceforge.net/p/gnv/bugs/82/ * -P is mapped to /NOLINE_DIRECTIVES. Formerly it was incorrectly mapped to /PREPROCESS. https://sourceforge.net/p/gnv/bugs/83/ * The CC/LD/CXX wrapper was not handling quoted macro definitions with spaces. https://sourceforge.net/p/gnv/bugs/86/ * A cc or cxx foreign command to the wrapper binary will no longer cause an infinite recursion. https://sourceforge.net/p/gnv/bugs/89/ * The --version used to display the C or C++ compiler version, and if the CC command was defined as a DCL symbol with more options, an error message "%DCL-I-IGNQUAL, qualifiers appearing before this item were ignored \VERSION\". This message is no longer displayed. * The --help output has been simplified. For full help use -v just like on Linux. * Missing files may cause CPU looping. Partial fix. Checks for missing libraries and shared images. Full fix not practical to implement at this time. GNV ticket: https://sourceforge.net/p/gnv/bugs/68/ https://sourceforge.net/p/gnv/bugs/82/ * When you specify a "-o path/foo" file for an action of "cc", "cxx", or "link", then the file "path/gnv$foo_${action}.com" will be run if it exists before the action is executed. Issues not fixed: * While this program will build on VAX, it currently does not work. * The -x xxx option is positional, not global. https://sourceforge.net/p/gnv/bugs/88/ * -W reports unsupported. -Wextra -Wno-missing-field-initializers https://sourceforge.net/p/gnv/bugs/81/ * Previously VMS specific options have been added to the LD/CC/CXX wrapper syntax. Some of these options are now conflicting with actual Posix CC commands. -W