163 lines
6.6 KiB
Plaintext
163 lines
6.6 KiB
Plaintext
Compiling EPICS and Building IOC Applications on HPUX 11 (hpux-parisc)
|
|
======================================================================
|
|
|
|
Please mail questions, comments, corrections, additional examples, etc.
|
|
to Ralph.Lange@bessy.de
|
|
|
|
NOTE: 3.14 will ONLY compile on HPUX 11 systems. HPUX 10 does not have
|
|
the necessary posix thread support and will never ever be
|
|
supported for EPICS base versions >= 3.14.
|
|
|
|
|
|
Tools needed
|
|
------------
|
|
|
|
o For compiling with HP native compilers
|
|
|
|
- HP's ANSI C compiler (cc)
|
|
|
|
- Recent version of HP's aCC C++ compiler aCC
|
|
(we currently use A.03.52; anything >= A.03.39 should also do)
|
|
HP's old frontend-based C++ compiler (CC) will not work.
|
|
|
|
o For compiling with the GNU compilers
|
|
|
|
- GNU assembler (part of the binutils package)
|
|
|
|
- GNU gcc/g++ >= 3 (I would suggest >= 3.2)
|
|
If you do not have GCC as a binary package, you can quite easily
|
|
build a GCC from scratch (aka "make bootstrap"). I was successful
|
|
using the following options to the configure script:
|
|
../configure
|
|
--prefix=<compiler install location>
|
|
--enable-version-specific-runtime-libs
|
|
--enable-languages=c++
|
|
--with-gnu-as
|
|
--with-as=<location of GNU assembler executable>
|
|
--enable-shared
|
|
--enable-threads=posix
|
|
Remember to set the install location of your GCC package in the
|
|
configuration file ../configure/os/CONFIG_SITE.Common.hpux-parisc-gnu
|
|
to make the EPICS builds use it.
|
|
|
|
IMPORTANT NOTE: aCC is the standard C++ compiler for EPICS on HP-UX 11.
|
|
Compiling Base with the GNU compiler set is experimental. Usually things
|
|
will compile, but applications may experience problems. (See below.) For
|
|
productional systems, using aCC is strictly recommended.
|
|
|
|
|
|
Environment
|
|
-----------
|
|
|
|
Default is compiling with the generic HP aCC compiler. To use the GNU
|
|
suite, set the environment variable EPICS_HOST_ARCH=hpux-parisc-gnu
|
|
before starting to compile base.
|
|
|
|
|
|
Building
|
|
--------
|
|
|
|
Should be quite straightforward. Edit the CONFIG_SITE files and "make".
|
|
(Be sure that GNU make is in your path or call it explicitly as the
|
|
standard make on HP is _not_ GNU.)
|
|
|
|
When compiling with aCC, you will see quite a few warning messages. Most
|
|
of these warnings - if not all - will be in system header files. There
|
|
is no decent way to suppress these warnings without suppressing the
|
|
warnings in the EPICS code. So close your eyes and stand it.
|
|
You may also note an unusual compile line that filters stuff through a
|
|
perl script. This is part of a mechanism that allows to selectively
|
|
block bogus warnings (using special comment lines) that are generated by
|
|
the HP compiler. Without this treatment you would see zillions of
|
|
warning messages. Feel free to try this by setting COMPILE_FILTER.cpp
|
|
empty on the compile line ... ;-)
|
|
|
|
|
|
Shared Libraries
|
|
----------------
|
|
|
|
Generating shared libraries is supported, suggested and the default.
|
|
|
|
If you are planning to carry around your binaries to other machines, you
|
|
have to set the shared library search path accordingly (i.e. to the
|
|
generic location where you will install the shared libraries of EPICS
|
|
base on the target machines). This is done in the configure area (in the
|
|
file ../configure/os/CONFIG_SITE.Common.hpux-parisc).
|
|
|
|
The setting of internal and external search paths for libraries is aimed
|
|
at stability. The order of search is:
|
|
1. Where the library was found at compile time. (always)
|
|
2. The INSTALL_LOCATION at compile time. (convenient when developing)
|
|
3. Any locations explicitly configured. (generic location)
|
|
4. The environment variable SHLIB_PATH. (fallback)
|
|
|
|
I changed the usual behaviour of "environment overrides default" to
|
|
increase reliability: As long as the libraries are in the generic
|
|
location, a user can set the environment wildly to anything without any
|
|
impact on the reliable operation of EPICS applications.
|
|
Still on systems where the libraries are not found at the generic place
|
|
(and you don't have the root privilege to put them there), setting the
|
|
environment you can point your client application to a fallback
|
|
location.
|
|
|
|
You can always change the order of search paths and disable usage of the
|
|
internal path and/or environment variable later on in the binary without
|
|
recompiling using the "chatr" (change attributes) command.
|
|
|
|
|
|
Known Possible Problems
|
|
-----------------------
|
|
|
|
o Using the GNU compiler is experimental.
|
|
- CA clients compiled with the GNU compiler have some serious
|
|
problems related to the connection loss management of Channel
|
|
Access. This shows up as sudden messages "Unable to contact CA
|
|
repeater" and loss of the CA repeater connection. When the IOC gets
|
|
back after a reboot, the client program may never reconnect and has
|
|
to be restarted. I will be looking into this problem so that
|
|
hopefully it will go away in a future release. But: aCC is the main
|
|
platform, getting things to run under GNU is a low priority task
|
|
for me, so any help is appreciated very much.
|
|
- Caveat: To be compatible with HP-UX 10, GCC defaults to use the DCE
|
|
(user space) threads package. If you see messages like "errLogInit
|
|
failed" when running a Channel Access client, you are probably
|
|
linking against the old DCE threads library instead of libpthread.
|
|
|
|
o The 3.13 compatibility mode has passed some general testing for both
|
|
native and GNU compilers with static and shared libraries and for
|
|
statically and dynamically linked builds. Not every combination has
|
|
been thoroughly tested. If the build system won't build your 3.13
|
|
application successfully, contact me.
|
|
|
|
|
|
Kernel Configuration
|
|
--------------------
|
|
|
|
HP-UX 11 has a kernel configuration parameter that limits the number of
|
|
threads that can be created within the context of a single process. This
|
|
parameter has a default of 64.
|
|
Channel Access creates two threads for each TCP connection it uses,
|
|
where one TCP connection usually corresponds to one client-server
|
|
pair. So a CA client program that connects to 30 different IOCs will use
|
|
60 threads for the CA communication.
|
|
|
|
Obviously it is advisable to increase that value from 64 to something
|
|
larger - any number higher than twice the maximum number of IOCs in your
|
|
system should be enough for regular concole systems. At some point you
|
|
will hit the limited number of kernel threads, which has to be larger
|
|
than the number uf user threads.
|
|
|
|
You will find the parameter in SAM's Kernel Configuration / Configurable
|
|
Parameters section, under the name max_thread_proc ("Max No. of Threads
|
|
allowed in each process").
|
|
|
|
Note that this kernel configuration change requires a reboot of the
|
|
machine.
|
|
|
|
|
|
So much for this README - please feel free to contact me if you
|
|
encounter serious problems.
|
|
|
|
Enjoy!
|
|
Ralph
|