Software-artifact Infrastructure Repository

• Home
• Download Objects
• Download Tools
• C Object Handbook
• Java Object Handbook
• Java Invariant Checking
  Examples Handbook
• SPL Object Handbook
• Concise Object Handbook
• C Object Preparer's Handbook
• Java Object Preparer's Handbook
• SPL Object Preparer's Handbook
• Concise Obj. Preparer's Handbook
• Reporting Experimental Results
• Citing SIR
• SIR Users and Publications
• Frequently Asked Questions
• Acknowledgments

Mike Ernst and Yuriy Brun (MIT) suggest the following:

Using the original distribution (found in originals), run configure, and replace the provided library(s) with the generated one(s). For example:

   tar xzf make-3.76.1.tar.gz
   cd make-3.76.1
   ./configure
   make

You then need to copy two files from the make-3.76.1 directory:

  config.h
  libglob.a

As Mike notes, an even better solution is to simply inline the glob routines in the big make.c file, just as all the C source files from the top-level directory were inlined in the big make.c file. Then there will be no dependence on a system-specific library.

Additional notes on SIR subject portability and provisioning

Since many of the C language subjects were originally developed for the Sun Solaris OS, you will need to concern yourself with porting these to your OS and compiler tools chain. Frequently this involves setting or unsetting the appropriate preprocessor flags so that the correct method of initializing system variables is used. For example, building the make subject using the GCC compiler tool chain typically requires setting the HAVE_SYS_SIGLIST and SYS_SIGLIST_DECLARED preprocessor compilation flags. The make subject (as do most of the other C subjects developed for SUN Solaris) provides for a shell variable to contain these compilation flag settings, so by setting the COMPILE_PARAMETERS to the appropriate preprocessing flag values permits successful compilation, e.g.:

For a Bash shell:
export COMPILE_PARAMETERS="-DHAVE_SYS_SIGLIST -DSYS_SIGLIST_DECLARED"

For Csh shell:
setenv COMPILE_PARAMETERS "-DHAVE_SYS_SIGLIST -DSYS_SIGLIST_DECLARED"

Once the COMPILE_PARAMETERS has been set in the shell, the make utility of your system will correctly locate and use the system library initialization of the sys_siglist variable. This is standard code porting and is dependent on the compiler tool chain and operating system. Other C subjects may require different compile flags, or compile flags commented out within the include files supplied (typically config.h.)

The Flex subject uses a local library (libfl.a) which must be rebuilt. Failing to rebuild this library will typically result in errors from the C compiler when performing the link-loader phase (/usr/bin/ld errors on Linux systems). To rebuild the library, compile the .c files found in the lib_src directory for each version of Flex using the -c flag, e.g.

cd lib_src
gcc -c libmain.c
gcc -c liballoc.c
gcc -c libstring.c
gcc -c libyywrap.c

Once compiled, the archive can be rebuilt. Remove the old libfl.a and from within the lib_src directory execute the ar command:

ar -c ../libfl.a libmain.o liballoc.o libstring.o libyywrap.o

Once libfl.a has been rebuilt for your platform, the compilation of flex.exe should complete successfully.

The flex subject also has a tendency to require specifying the type of memory allocation library to use. If flex fails to build, and one of the warning messages is similar to:

flex.c:8130:7: warning: conflicting types for built-in function '__builtin_alloca' [enabled by default]

followed by the compilation/linker error similar to:

flex.o: In function `yyparse’:
flex.c:(.text+0xaec9): undefined reference to `__builtin_alloca'
flex.c:(.text+0xaefd): undefined reference to `__builtin_alloca'
collect2: error: ld returned 1 exit status

(the warning's line number may vary by version being compiled), this indicates you need the preprocessor symbol -DHAVE_ALLOCA_H set in the COMPILE_PARAMETERS as described above. Other subjects may require this or differing preprocessor symbols to be enabled, so a judicious code inspection for cpp(1) directives in the source lines immediately before the location of the warning will typically reveal which preprocessor symbol should be required. While this example is specific to flex it can apply to any of the C subjects in the repository, the solution to compilation problems is typically setting the correct preprocessor symbol to activate the block of code that supports your host system OS and hardware architecture.

The replace subject overrides functions in the stdio.h library which necessitate informing the compiler of this override. For most compiler tool chains you can use the -std=c89 -pedantic flags to the C compiler which will permit this to be overridden.

The testing subjects available from the SIR have been prepared using Linux, UNIX, and Solaris operating systems. The subjects may provide scripts that provision and execute tests upon the subject in an automated fashion which will require extensive modification to operate on non-UNIX derived systems (e.g. Microsoft Windows platforms.) There are several options that you can investigate if you want to run these experiments using Microsoft platforms. Cygwin provides a tool collection that allows running scripts targetted at UNIX/Linux systems and should provide most of the needed capabilities to support experimentation. The UWIN package from AT&T Research provides another tool collection that provides UNIX/Linux command emulation suitble for running the scripts provided with these subjects. As always, a virtual machine instance provided by VirtualBox or VMWare as well as virtual machine hosting capabilities built into certain operating systems can provide the needed platform to execute the subject scripts. Depending upon which of these options you choose, there may be changes required within the scripts in order for them to execute in that environment.

With more recent architectures some include files that were provided by the Linux platforms are no longer available. Typically you will need to locate where the defined elements that were included in that file have moved to, and a web search for the missing include file will often yield a result you can use. One such case is with the grep subject. With grep the libintl.h file has an include of sys/isa_defs.h which no longer exists. A web search finds that one project on GitHub makes a reference to this file and that reference contains only one line that includes linux_types.h . Using this information, you can look for linux_types.h but it doesn't exist either. Noticing that there is a types.h in the Linux /usr/include/sys directory, a change of that include from sys/isa_defs.h to sys/types.h allows grep to build successfully. Other times you will need to find what was actually defined within the include file, which can again be found by web searching.