How to compile shared C library on zOS

Question

I have several source files in C with one function per file. I have to compile it to shared library on z/OS using xlc compiler.

I'm compiling C files with

xlc -c -O2 -o o/func1.o func1.c

later on I create lib file with

xlc -o library.o o/*.o

I wonder if this is the correct way to create shared library in Z/OS ?

Does anyone has got more experience and help me out with it ?

Answer 1

Posting on behalf of very knowledgeable developer.

On z/OS, shared libraries are called DLL’s and you need to specify the DLL option to generate one. Here is an example of how to do so and how to create an application using the DLL. Note that you still will need to export the functions (and data) you want other modules to access. This can be done either through the #pragma export directive (https://www.ibm.com/docs/en/zos/3.1.0?topic=descriptions-pragma-export) or the EXPORTALL compiler option (https://www.ibm.com/docs/en/zos/3.1.0?topic=options-exportall-noexportall) for example. Details can be found here: https://www.ibm.com/docs/en/zos/3.1.0?topic=dlls-building-dll-application

xlc library.c -qdll -Wl,dll -o library.dll # Creates the DLL

xlc main.c library.x -qdll -o runme # Create the application that will use the DLL. The .x file is the sidedeck created by the first command.

You can use the LIBPATH environment variable to point to the directory of the DLL when you run the application.

Answer 2

To be a little more precise, you need to specify the -Wl,DLL option to build a DLL on z/OS. The -qdll enchances the code gen in non-xplink mode to support DLL's. Any code that will call a DLL or will be inside of a DLL needs to be compiled with that option. If you are compiling in XPLINK mode (i.e with -qxplink or in 64-bit mode) you don't need the -qdll option. All code compiled in XPLINK mode support DLLs.

For the OpenXL compiler, building a DLL is even simpler. You don't need any extra compile options since OpenXL v1.1 only generates 64-bit XPLINK code. On the link step you add the --shared option. For example:

ibm-clang64 --shared -o dll.so source.c

I assume since you are building a shared library you will want to link to it and use it. To do that you produce a list of functions and variables that other DLL's or the main program can use. This is referred to as exporting symbols. You can do this in one of three ways:

• using #pragma export
• using the _Export keyword
• using the -qexportall (xlc) or -fvisibility=default (ibm-clang64)

See the product docs for more info about each of these. Once you have compiled the source with one or more of these methods, the link step will produce two output files for the DLL. You'll get the actual DLL along with an additional file referred to the import file or side deck. This file will have the same name as the DLL but will have the extension .x. So if you use -o DLL.so, the side deck will be called DLL.x.

You then use the side deck in any link step that wants to use the DLL. For example:

ibm-clang64 -o myprog main.c DLL.x
xlC -q64 -o myprog main.c DLL.x  # works for -q32 & -qxplink too

Then at runtime you will set LIBPATH and/or STEPLIB, depending on where the DLL will reside, so the system loader knows where to find the DLL. If the DLL is on USS you would use LIBPATH to specify the list of directories to search for the DLL. If the DLL is in a data set you would use STEPLIB to specify the list of data sets to search for the DLL. For example:

LIBPATH=.:$LIBPATH ./myprog

If the DLL was going to be saved into a data set, you will have to make sure that the side deck is updated to specify the name of the DLL in the data set. Let's say you have renamed the DLL from DLL.so to some name that is data set friendly and you have updated the side deck BEFORE linking the main programs and you have copied the the DLL into the data set USER.SCEERUN2. Running the program would look like:

STEPLIB=USER.SCEERUN2:$STEPLIB ./myprog

I hope this helps you to get up and using shared libraries on z/OS.

One final thought, z/OS determines where symbols are found at link step via the side decks not at runtime like on Linux. An import list of symbols and dlls is saved in the program. Through the use of multiple DLL's you can have a program have multiple symbols with the same name. A single DLL will only refer to one symbol for a given name, but different DLLs can refer to different symbols for the same name.