DOCSLIB.ORG

Building Multi-File Programs with the Make Tool

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Building Multi-File Programs with the Make Tool Princeton University Computer Science 217: Introduction to Programming Systems Agenda Motivation for Make Building Multi-File Programs Make Fundamentals with the make Tool Non-File Targets Macros Implicit Rules 1 2 Multi-File Programs Motivation for Make (Part 1) intmath.h (interface) Building testintmath, approach 1: testintmath.c (client) #ifndef INTMATH_INCLUDED • Use one gcc217 command to #define INTMATH_INCLUDED #include "intmath.h" int gcd(int i, int j); #include <stdio.h> preprocess, compile, assemble, and link int lcm(int i, int j); #endif int main(void) { int i; intmath.c (implementation) int j; printf("Enter the first integer:\n"); #include "intmath.h" scanf("%d", &i); testintmath.c intmath.h intmath.c printf("Enter the second integer:\n"); int gcd(int i, int j) scanf("%d", &j); { int temp; printf("Greatest common divisor: %d.\n", while (j != 0) gcd(i, j)); { temp = i % j; printf("Least common multiple: %d.\n", gcc217 testintmath.c intmath.c –o testintmath i = j; lcm(i, j); j = temp; return 0; } } return i; } Note: intmath.h is int lcm(int i, int j) #included into intmath.c { return (i / gcd(i, j)) * j; testintmath } and testintmath.c 3 4 Motivation for Make (Part 2) Partial Builds Building testintmath, approach 2: Approach 2 allows for partial builds • Preprocess, compile, assemble to produce .o files • Example: Change intmath.c • Link to produce executable binary file • Must rebuild intmath.o and testintmath • Need not rebuild testintmath.o!!! Recall: -c option tells gcc217 to omit link changed testintmath.c intmath.h intmath.c testintmath.c intmath.h intmath.c gcc217 –c testintmath.c gcc217 –c intmath.c gcc217 –c testintmath.c gcc217 –c intmath.c testintmath.o intmath.o testintmath.o intmath.o gcc217 testintmath.o intmath.o –o testintmath gcc217 testintmath.o intmath.o –o testintmath testintmath testintmath 5 6 Partial Builds Partial Builds • Example: Change testintmath.c However, changing a .h file can be more dramatic • Must rebuild testintmath.o and testintmath • Example: Change intmath.h • Need not rebuild intmath.o!!! • intmath.h is #included into testintmath.c and intmath.c • Changing intmath.h effectively changes testintmath.c If program contains many .c files, could save many hours of build time and intmath.c • Must rebuild testintmath.o, intmath.o, and testintmath changed changed testintmath.c intmath.h intmath.c testintmath.c intmath.h intmath.c gcc217 –c testintmath.c gcc217 –c intmath.c testintmath.o intmath.o gcc217 –c testintmath.c gcc217 –c intmath.c testintmath.o intmath.o gcc217 testintmath.o intmath.o –o testintmath gcc217 testintmath.o intmath.o –o testintmath testintmath testintmath 7 8 Wouldn’t It Be Nice… Agenda Observation • Doing partial builds manually is tedious and error-prone • Wouldn䇻t it be nice if there were a tool Motivation for Make How would the tool work? Make Fundamentals • Input: • Dependency graph (as shown previously) Non-File Targets • Specifies file dependencies • Specifies commands to build each file from its dependents Macros • Date/time stamps of files Implicit Rules • Algorithm: • If file B depends on A and date/time stamp of A is newer than date/time stamp of B, then rebuild B using the specified command That䇻s make! 9 10 Make Command Syntax Dependency Rules in Makefile Command syntax Dependency rule syntax $ man make target: dependencies SYNOPSIS <tab>command make [-f makefile] [options] [targets] • target: the file you want to build • makefile • dependencies: the files on which the target depends • Textual representation of dependency graph • command: (after a TAB character) what to execute to • Contains dependency rules create the target • Default name is makefile, then Makefile Dependency rule semantics • Build target iff it is older than any of its dependencies • target • Use command to do the build • What make should build • Usually: .o file, or an executable binary file • Default is first one defined in makefile Work recursively; examples illustrate… 11 12 Makefile Version 1 Version 1 in Action testintmath.c intmath.h intmath.c At first, to build testintmath Use the touch command to make issues all three gcc change the date/time stamp gcc217 –c testintmath.c gcc217 –c intmath.c commands of intmath.c testintmath.o intmath.o $ make testintmath gcc217 -c testintmath.c gcc217 testintmath.o intmath.o –o testintmath gcc217 -c intmath.c gcc217 testintmath.o intmath.o -o testintmath $ touch intmath.c testintmath Makefile: $ make testintmath gcc217 -c intmath.c testintmath: testintmath.o intmath.o gcc217 testintmath.o intmath.o -o testintmath gcc217 testintmath.o intmath.o –o testintmath $ make testintmath make: `testintmath' is up to date. testintmath.o: testintmath.c intmath.h make does a partial build gcc217 -c testintmath.c $ make make: `testintmath' is up to date. make notes that the specified intmath.o: intmath.c intmath.h gcc217 -c intmath.c target is up to date The default target is testintmath, 13 the target of the first dependency rule 14 Agenda Non-File Targets Adding useful shortcuts for the programmer • make all: create the final executable binary file Motivation for Make • make clean: delete all .o files, executable binary file • make clobber: delete all Emacs backup files, all .o files, executable Make Fundamentals Commands in the example Non-File Targets • rm –f: remove files without querying the user • Files ending in 䇺~䇻 and starting/ending in 䇺#䇻 are Emacs backup files Macros Implicit Rules all: testintmath clobber: clean rm -f *~ \#*\# clean: rm -f testintmath *.o 15 16 Makefile Version 2 Version 2 in Action # Dependency rules for non-file targets make observes that 䇾clean䇿 target all: testintmath doesn䇻t exist; attempts to build it clobber: clean rm -f *~ \#*\# by issuing 䇾rm䇿 command clean: Same idea here, but rm -f testintmath *.o $ make clean rm -f testintmath *.o 䇾clobber䇿 depends upon 䇾clean䇿 # Dependency rules for file targets $ make clobber testintmath: testintmath.o intmath.o rm -f testintmath *.o gcc217 testintmath.o intmath.o –o testintmath rm -f *~ \#*\# testintmath.o: testintmath.c intmath.h $ make all gcc217 -c testintmath.c gcc217 -c testintmath.c gcc217 -c intmath.c intmath.o: intmath.c intmath.h gcc217 testintmath.o intmath.o -o testintmath gcc217 -c intmath.c $ make make: Nothing to be done for `all'. 䇾all䇿 depends upon 䇾testintmath䇿 䇾all䇿 is the default target 17 18 Agenda Macros make has a macro facility • Performs textual substitution Motivation for Make • Similar to C preprocessor’s #define Make Fundamentals Macro definition syntax Non-File Targets macroname = macrodefinition • make replaces $(macroname) with macrodefinition in remainder of Macros Makefile Implicit Rules Example: Make it easy to change build commands CC = gcc217 Example: Make it easy to change build flags CFLAGS = -D NDEBUG –O 19 20 Makefile Version 3 Version 3 in Action # Macros CC = gcc217 # CC = gcc217m Same as Version 2 CFLAGS = # CFLAGS = -g # CFLAGS = -D NDEBUG # CFLAGS = -D NDEBUG -O # Dependency rules for non-file targets all: testintmath clobber: clean rm -f *~ \#*\# clean: rm -f testintmath *.o # Dependency rules for file targets testintmath: testintmath.o intmath.o $(CC) $(CFLAGS) testintmath.o intmath.o -o testintmath testintmath.o: testintmath.c intmath.h $(CC) $(CFLAGS) -c testintmath.c intmath.o: intmath.c intmath.h $(CC) $(CFLAGS) -c intmath.c 21 22 Agenda Implicit Rules make has implicit rules for compiling and linking C programs • make knows how to build x.o from x.c Motivation for Make • Automatically uses $(CC) and $(CFLAGS) Make Fundamentals • make knows how to build an executable from .o files • Automatically uses $(CC) Non-File Targets intmath.o: intmath.c intmath.h Macros $(CC) $(CFLAGS) –c intmath.c Implicit Rules intmath.o: intmath.c intmath.h testintmath: testintmath.o intmath.o $(CC) testintmath.o intmath.o –o testintmath testintmath: testintmath.o intmath.o 23 24 Makefile Version 4 Version 4 in Action # Macros CC = gcc217 # CC = gcc217m Same as Version 2 CFLAGS = # CFLAGS = -g # CFLAGS = -D NDEBUG # CFLAGS = -D NDEBUG -O # Dependency rules for non-file targets all: testintmath clobber: clean rm -f *~ \#*\# clean: rm -f testintmath *.o # Dependency rules for file targets testintmath: testintmath.o intmath.o testintmath.o: testintmath.c intmath.h intmath.o: intmath.c intmath.h 25 26 Implicit Dependencies Makefile Version 5 has implicit rules for inferring dependencies make # Macros • make will assume that x.o depends upon x.c CC = gcc217 # CC = gcc217m CFLAGS = # CFLAGS = -g # CFLAGS = -D NDEBUG # CFLAGS = -D NDEBUG -O intmath.o: intmath.c intmath.h # Dependency rules for non-file targets all: testintmath clobber: clean rm -f *~ \#*\# clean: intmath.o: intmath.h rm -f testintmath *.o # Dependency rules for file targets testintmath: testintmath.o intmath.o testintmath.o: intmath.h intmath.o: intmath.h 27 28 Version 5 in Action iClicker Question Q: If you were making a Makefile for this program, what should a.o depend on? Same as Version 2 d.h A. a.c c.h a.h B. a.c a.h a.c b.c C. a.c c.h d.h a.o b.o D. a.c a.h c.h d.h a 29 Makefile Guidelines iClicker Question Q: If you were making a Makefile for this program, d.h what should a depend on? c.h a.h d.h a.c b.c A. a.o b.o c.h a.h a.o b.o a.o: a.h c.h d.h B. a.o b.o a.c b.c a.c b.c a C. a.o b.o a.h c.h d.h a.o b.o In a proper Makefile, each object file: D. a.c b.c a.h c.h d.h • Depends upon its .c file (but can rely on an implicit dependency) a • Does not depend upon any other .c file E.
Load more

Recommended publications
  • Red Hat Developer Toolset 9 User Guide
    Red Hat Developer Toolset 9 User Guide Installing and Using Red Hat Developer Toolset Last Updated: 2020-08-07 Red Hat Developer Toolset 9 User Guide Installing and Using Red Hat Developer Toolset Zuzana Zoubková Red Hat Customer Content Services Olga Tikhomirova Red Hat Customer Content Services [email protected] Supriya Takkhi Red Hat Customer Content Services Jaromír Hradílek Red Hat Customer Content Services Matt Newsome Red Hat Software Engineering Robert Krátký Red Hat Customer Content Services Vladimír Slávik Red Hat Customer Content Services Legal Notice Copyright © 2020 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/ . In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp.
    [Show full text]
  • Download Chapter 3: "Configuring Your Project with Autoconf"
    CONFIGURING YOUR PROJECT WITH AUTOCONF Come my friends, ’Tis not too late to seek a newer world. —Alfred, Lord Tennyson, “Ulysses” Because Automake and Libtool are essen- tially add-on components to the original Autoconf framework, it’s useful to spend some time focusing on using Autoconf without Automake and Libtool. This will provide a fair amount of insight into how Autoconf operates by exposing aspects of the tool that are often hidden by Automake. Before Automake came along, Autoconf was used alone. In fact, many legacy open source projects never made the transition from Autoconf to the full GNU Autotools suite. As a result, it’s not unusual to find a file called configure.in (the original Autoconf naming convention) as well as handwritten Makefile.in templates in older open source projects. In this chapter, I’ll show you how to add an Autoconf build system to an existing project. I’ll spend most of this chapter talking about the fundamental features of Autoconf, and in Chapter 4, I’ll go into much more detail about how some of the more complex Autoconf macros work and how to properly use them. Throughout this process, we’ll continue using the Jupiter project as our example. Autotools © 2010 by John Calcote Autoconf Configuration Scripts The input to the autoconf program is shell script sprinkled with macro calls. The input stream must also include the definitions of all referenced macros—both those that Autoconf provides and those that you write yourself. The macro language used in Autoconf is called M4. (The name means M, plus 4 more letters, or the word Macro.1) The m4 utility is a general-purpose macro language processor originally written by Brian Kernighan and Dennis Ritchie in 1977.
    [Show full text]
  • Assessing Unikernel Security April 2, 2019 – Version 1.0
    NCC Group Whitepaper Assessing Unikernel Security April 2, 2019 – Version 1.0 Prepared by Spencer Michaels Jeff Dileo Abstract Unikernels are small, specialized, single-address-space machine images constructed by treating component applications and drivers like libraries and compiling them, along with a kernel and a thin OS layer, into a single binary blob. Proponents of unikernels claim that their smaller codebase and lack of excess services make them more efficient and secure than full-OS virtual machines and containers. We surveyed two major unikernels, Rumprun and IncludeOS, and found that this was decidedly not the case: unikernels, which in many ways resemble embedded systems, appear to have a similarly minimal level of security. Features like ASLR, W^X, stack canaries, heap integrity checks and more are either completely absent or seriously flawed. If an application running on such a system contains a memory corruption vulnerability, it is often possible for attackers to gain code execution, even in cases where the applica- tion’s source and binary are unknown. Furthermore, because the application and the kernel run together as a single process, an attacker who compromises a unikernel can immediately exploit functionality that would require privilege escalation on a regular OS, e.g. arbitrary packet I/O. We demonstrate such attacks on both Rumprun and IncludeOS unikernels, and recommend measures to mitigate them. Table of Contents 1 Introduction to Unikernels . 4 2 Threat Model Considerations . 5 2.1 Unikernel Capabilities ................................................................ 5 2.2 Unikernels Versus Containers .......................................................... 5 3 Hypothesis . 6 4 Testing Methodology . 7 4.1 ASLR ................................................................................ 7 4.2 Page Protections ....................................................................
    [Show full text]
  • AMD Optimizing CPU Libraries User Guide Version 2.1
    [AMD Public Use] AMD Optimizing CPU Libraries User Guide Version 2.1 [AMD Public Use] AOCL User Guide 2.1 Table of Contents 1. Introduction .......................................................................................................................................... 4 2. Supported Operating Systems and Compliers ...................................................................................... 5 3. BLIS library for AMD .............................................................................................................................. 6 3.1. Installation ........................................................................................................................................ 6 3.1.1. Build BLIS from source .................................................................................................................. 6 3.1.1.1. Single-thread BLIS ..................................................................................................................... 6 3.1.1.2. Multi-threaded BLIS .................................................................................................................. 6 3.1.2. Using pre-built binaries ................................................................................................................. 7 3.2. Usage ................................................................................................................................................. 7 3.2.1. BLIS Usage in FORTRAN ................................................................................................................
    [Show full text]
  • Nios II Software Build Tools Reference January 2014 NII52016-13.1.0
    15. Nios II Software Build Tools Reference January 2014 NII52016-13.1.0 NII52016-13.1.0 This chapter provides a complete reference of all available commands, options, and settings for the Nios® II Software Build Tools (SBT). This reference is useful for developing your own embedded software projects, packages, or device drivers. f Before using this chapter, read the Getting Started from the Command Line chapter of the Nios II Software Developer’s Handbook, and familiarize yourself with the parts of the Nios II Software Build Tools chapter of the Nios II Software Developer’s Handbook that are relevant to your tasks. This chapter includes the following sections: ■ “Nios II Software Build Tools Utilities” on page 15–1 ■ “Nios II Design Example Scripts” on page 15–31 ■ “Settings Managed by the Software Build Tools” on page 15–34 ■ “Application and User Library Makefile Variables” on page 15–73 ■ “Software Build Tools Tcl Commands” on page 15–76 ■ “Software Build Tools Path Names” on page 15–122 Nios II Software Build Tools Utilities The build tools utilities are an entry point to the Nios II SBT. Everything you can do with the tools, such as specifying settings, creating makefiles, and building projects, is made available by the utilities. All Nios II SBT utilities share the following behavior: ■ Sends error messages and warning messages to stderr. ■ Sends normal messages (other than errors and warnings) to stdout. ■ Displays one error message for each error. ■ Returns an exit value of 1 if it detects any errors. ■ Returns an exit value of 0 if it does not detect any errors.
    [Show full text]
  • [Version 2017R4] How to Install Required Libraries Under GNU/Linux
    Documentation of the chemistry-transport model [version 2017r4] July 25, 2018. How to install required libraries under GNU/Linux Contents 1 pNetCDF and NetCDF4 formats 2 1.1 Problems with NetCDF4 files . .2 1.2 How to use CHIMERE with already prepared NetCDF4 files? . .2 1.3 In case of use of WRF . .2 2 Libraries to install 3 2.1 Installation of MPI . .3 2.1.1 With gfortran on a 64 bit system . .3 2.1.2 With ifort on a 64 bit system . .3 2.2 Installation of NetCDF and pNetCDF . .4 2.3 Compilation with intel . .4 2.4 Compilation with gfortran . .5 1 1 pNetCDF and NetCDF4 formats 1.1 Problems with NetCDF4 files pNetCDF is not able to open netcdf4 files as explained in this website: https://trac.mcs.anl.gov/projects/parallel-netcdf and with the following text on their site: "NetCDF gives scientific programmers a self-describing and portable means for storing data. However, prior to version 4, netCDF does so in a serial manner. NetCDF started to support parallel I/O from version 4, whose parallel I/O feature was at first built on top of parallel HDF5. Thus, the file format required by NetCDF-4 parallel I/O operations was restricted to HDF5 format. Starting from the release of 4.1, NetCDF has also incorporated PnetCDF library to enable parallel I/O operations on files in classic formats (CDF-1 and 2). Official support for the CDF-5 format started in the release of NetCDF 4.4.0. Note NetCDF now can be built with PnetCDF as its sole parallel I/O mechanism by using command-line option "–disable-netcdf-4 –enable-pnetcdf".
    [Show full text]
  • Latticemico8 Development Tools User Guide
    LatticeMico8 Development Tools User Guide Copyright Copyright © 2010 Lattice Semiconductor Corporation. This document may not, in whole or part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine- readable form without prior written consent from Lattice Semiconductor Corporation. Lattice Semiconductor Corporation 5555 NE Moore Court Hillsboro, OR 97124 (503) 268-8000 October 2010 Trademarks Lattice Semiconductor Corporation, L Lattice Semiconductor Corporation (logo), L (stylized), L (design), Lattice (design), LSC, CleanClock, E2CMOS, Extreme Performance, FlashBAK, FlexiClock, flexiFlash, flexiMAC, flexiPCS, FreedomChip, GAL, GDX, Generic Array Logic, HDL Explorer, IPexpress, ISP, ispATE, ispClock, ispDOWNLOAD, ispGAL, ispGDS, ispGDX, ispGDXV, ispGDX2, ispGENERATOR, ispJTAG, ispLEVER, ispLeverCORE, ispLSI, ispMACH, ispPAC, ispTRACY, ispTURBO, ispVIRTUAL MACHINE, ispVM, ispXP, ispXPGA, ispXPLD, Lattice Diamond, LatticeEC, LatticeECP, LatticeECP-DSP, LatticeECP2, LatticeECP2M, LatticeECP3, LatticeMico8, LatticeMico32, LatticeSC, LatticeSCM, LatticeXP, LatticeXP2, MACH, MachXO, MachXO2, MACO, ORCA, PAC, PAC-Designer, PAL, Performance Analyst, Platform Manager, ProcessorPM, PURESPEED, Reveal, Silicon Forest, Speedlocked, Speed Locking, SuperBIG, SuperCOOL, SuperFAST, SuperWIDE, sysCLOCK, sysCONFIG, sysDSP, sysHSI, sysI/O, sysMEM, The Simple Machine for Complex Design, TransFR, UltraMOS, and specific product designations are either registered trademarks or trademarks of Lattice Semiconductor Corporation
    [Show full text]
  • The Make Utility
    The Make Utility Independent compilation • Large programs are difficult to maintain • Problem solved by breaking the program into separate files • Different functions placed in different files • The main function appears in only one file, conventionally known as main.c • Advantages – Reduction in complexity of organizing the program – Reduction in time required for compilation ∗ Each file is compiled separately ∗ Only those files are recompiled that have been modified • Compiler creates object files corresponding to each source file • The object files are linked together to create the final executable • Compilation time is reduced because linking is much faster than compilation • Source files are compiled separately under Unix using the -c option to the compiler gcc -c main.c • The entire sequence of commands to create an executable can be specified as gcc -c main.c gcc -c func.c gcc -o prog main.o func.o Header files • Used to keep information common to multiple source files • Files need the same #define declarations and the same type declarations (struct and typedef) • More convenient to declare these declarations in a single header file • Header file can be used in all the files using #include • Such a process avoids duplication and allows for easier modification since a constant or type declaration need only be changed in one place • Guidelines for good header file usage – Header files should contain only ∗ Constant definitions ∗ Type declarations ∗ Macro definitions ∗ Extern declarations ∗ Function prototypes The Make Utility 2 – Header files should not
    [Show full text]
  • Preprocessing/Compiling/Linking
    1967-6 Advanced School in High Performance and GRID Computing 3 - 14 November 2008 From Source Code to Executable: Preprocessing / Compiling / Linking Makefiles (Part I) KOHLMEYER Axel University of Pennsylvania Department of Chemistry 231 South 34th Street PA 19104 Philadelphia U.S.A. From Source Code to Executable: Preprocessing, Compiling, Linking, and Makefiles ICTP Advanced School in High Performance and GRID Computing Axel Kohlmeyer Center for Molecular Modeling ICTP, Trieste – Italy, 04 November 2008 Overview / Compiler ● The pre-process/compile/link process: the individual steps in detail ● Preprocessing in C and Fortran ● The C-preprocessor, typical directives ● Compilers: Fortran 77/95, C, C++ Vendors: GNU, Intel ● Special Compiler flags ● Special Linker flags, Utilities Pre-process / Compile / Link ● Consider the minimal C program 'hello.c': #include <stdio.h> int main(int argc, char **argv) { printf( hello world\n ); return 0; } ● What happens, if we do?: > cc -o hello hello.c (try: cc -v -o hello hello.c) Step 1: Pre-processing ● Preprocessing will handle all '#' directives – File inclusion – Conditional compilation – Macro expansion ● In this case: /usr/include/stdio.h is inserted and pre-processed ● Only pre-processing with -E flag: > cc -E -o hello.pp.c hello.c ● Last part of hello.pp.c and hello.c identical Step 2: Compilation ● Compiler converts high-level language ● Output machine specific text (assembly) ● Parses text (lexical + syntactical analysis) ● Test for correctness, language dialect ● Translate to internal
    [Show full text]
  • Intermediate Supercomputing Course Objectives
    Intermediate Supercomputing Course Objectives • Understand basic concepts of parallel programming • Compile and run code on Pawsey’s supercomputers • Develop and use advanced job scripts • Understand how to get good performance out of the filesystem OVERVIEW OF EXERCISES Exercise Files • Pi Darts program • Computes the value of Pi using Monte Carlo method A(C) = π R2 A(S) = 4R2 A(C) π = 4 A(S) 2r # darts in circle π = 4 # darts in square Exercise Files • Accuracy of Pi depends on number of darts • Multiple versions: • serial, • Python, • Intel MKL, • OpenMP, • MPI and MPI collective, • MPI+OpenMP hybrid, • CUDA GPU. • Exercises will involve editing, compiling, and launching job scripts Downloading exercises • Log in to Magnus via ssh: ssh [email protected] • Change directory to $MYGROUP cd $MYGROUP • Use git to download the exercise material: git clone https://github.com/PawseySupercomputing/Intermediate-Supercomputing.git Change into the downloaded directory: cd Intermediate-Supercomputing • List the contents of the directory: ls Darts Source Code • Separate directories for each version of the code e.g.: darts/serial • C and FORTRAN versions • C version today, but the instructions are transferable to FORTRAN • .c files • Where the action happens • .h files • Header files • Declaration of functions and directives • Allows us to use outside libraries (modularity) • Makefile • Recipe for how to compile code in a single step • Queueing script: job.slurm Submitting exercises Always use the SLURM reservation ID: sbatch --reservation=[RESERVATION_ID]
    [Show full text]
  • The Summit Programming Environment
    The Summit Programming Environment Matt Belhorn Oak Ridge Leadership Computing Facility Summit Training Workshop 3 December 2018 ORNL is managed by UT-Battelle LLC for the US Department of Energy What is the Programming Environment? Your Applications & Jobs Performance Scalable Math & Parallel Resource Debuggers Libraries & Userland & Workload Compiler Tools Analysis Managers IO Service Programming Toolchains & Utilities & Model Utilities Runtimes Runtimes LLCA, Networks Common Linux Runtime Libraries Operating System Hardware 2 Programming Environment Overview • At the highest level, the PE is your shell’s build- and run-time environment (see output of env). • Software outside default paths (/usr/bin, /usr/lib, etc.) • Managed via session environment variables – Search paths • PATH, LD_LIBRARY_PATH, LIBRARY_PATH, PKG_CONFIG_PATH, etc… – Program environment options • OMPI_*, CC, FC, ect… • Summit uses LMOD for this purpose 3 LMOD Environment Modules • Much of software available cannot coexist simultaneously in your environment. • Build- and runtime-environment software managed with LMOD (https://lmod.readthedocs.io) • Usage: $ module -t list # list loaded modules $ module avail # Show modules that can be loaded given current env $ module help <package> # Help info for package (if provided) $ module show <package> # Show contents of module $ module load <package> <package>… # Add package(s) to environment $ module unload <package> <package>… # Remove package(s) from environment $ module reset # Restore system defaults $ module restore <collection> # Load a saved collection $ module spider <package> # Deep search for modules $ module purge # Clear all modules from env. 4 Module Avail • The module avail command shows only what can be loaded given currently loaded packages. • Full or partial package names limit output to matches. $ module -w 80 avail Path in MODULEPATH ------------- /sw/summit/modulefiles/site/linux-rhel7-ppc64le/Core ------------- ..
    [Show full text]
  • Installation of Openpalm on Mac OS X
    CERFACS Reports - GLOBC Team 1 Installation of OpenPALM on Mac OS X By The OpenPALM Teamy 1. Download of the latest stable OpenPALM distribution The latest stable release of OpenPALM is downloadable from the OpenPALM web site (Fig. 1): http://www.cerfacs.fr/globc/PALM WEB/ The instructions to download OpenPALM are accessible from the page Become a user. In order to inform the OpenPALM Team of your download, you have to fill a form (Fig. 2). 2. Introduction In the OpenPALM distribution you will find the source codes of the OpenPALM library, of its interface and of all the sessions of the training. The first thing to do is to decompress the gzipped tar archive of the distribution: 1 > t a r −xvfz distrib.tgz Two directories are created: PrePALM MP and PALM MP. The first one contains the graphical user interface PrePALM, the second one the OpenPALM library. Note that the OpenPALM manual is in PrePALM/DOC (in english as well as in french) and that the sources for the training sessions are in PrePALM/training 3. Installation of the PrePALM graphical user interface 3.1. Pre-requirements The graphical interface PrePALM is written in Tcl/Tk with some C. Therefore you need these two environments on the machines where PrePALM has to run. The Tcl/Tk version has to be at least 8.3. A small C program is used to interpret the STEPLANG language: it is therefore necessary to compile this component. A pre-compiled version working on i386 to i686 and x86 64 platforms is provided with the OpenPALM distribution.
    [Show full text]