Make EPICS libraries Multiarch-aware

[ralphlange]

The EPICS Base libraries are not Multi-Arch-aware, i.e. i386 and amd64 architectures are not co-installable.

Currently this affects me as the BESSY dm2k uses a commercial widget (XRT/graph), that we only have in 32bit binary form. Installing this dm2k forces using all 32bit EPICS.

[ralphlange]

This will also need changes in epics-debhelper, as the standard locations for libraries change.

[mark0n]

I think this issue should be addressed as soon as possible since EPICS would benefit a lot from clean and easy cross-builds. As far as I can see changes by multi-arch affect: a) include dirs b) library dirs c) installation dirs

Since EPICS is still using its own old Makefile build-system some changes are necessary to build on both multi-arch and non-multiarch systems. The first and to my mind most significant piece of the solution is detecting the correct multiarch name (i.e. "tuple"/"triplet"). Can this be determined by looking at the EPICS_HOST_ARCH or do we have to detect it automatically? To me this problem seems to be similar to the problems other build tools face. If auto-detection is needed, it might help to have a look at how other build tools manage to do it? See e.g. http://public.kitware.com/Bug/view.php?id=12037

[mark0n]

A propos CMake: Some time ago Michael and I were fiddling around with a CMake-based EPICS build. In principle it should be rather easy to make the existing CMake rules multi-arch compatible since CMake is supposed to take care of all these things. As far as I can see we only have to use CMake >=2.8.5 (thus needs backport for build on squeeze) and to avoid certain issues that break multi-arch compatibility (e.g. hard-coded /usr/lib paths in Find.*.cmake files).

I think updating the existing CMake rules for the newest revision of base shouldn't be too much effort. As far as I can see, the main reasons CMake isn't used by anyone are: a) CMake does not support all architectures EPICS supports (VxWorks, RTEMS) b) the existing rules do not support building existing apps against them using the old build system since they do not provide the files in the configure directory (are any other files needed?)

a) should not be an issue for building Debian packages since Debian does not support these platform either b) I'm wondering if it is possible to generate these files from the CMake rules? How much effort would this be?

[ralphlange]

Hm. Maybe you are mixing up things a bit.

This repository is about Debian-packaging of EPICS base. This issue is about enabling the Multi-Arch feature of Debian, that - for the time being - covers co-installing libraries for multiple Debian architectures on the same machine. [1,2] The only change that I see for epics-base will be the install location of libraries in non-dev packages, that will move from /usr/lib to /usr/lib/$(DEB_HOST_MULTIARCH). There seems to be no Debian policy concerning include files yet, and packagers are asked to wait for that policy before providing Multi-Arch -dev packages with include files. [2]

All your other issues (cross-builds, cmake, ...) are upstream related and OT here. They are definitely worth discussing, but rather on core-talk@aps.anl.gov - would you mind re-posting there?

[1] https://wiki.debian.org/Multiarch [2] https://wiki.debian.org/Multiarch/Implementation

[mark0n]

Hmm, you're right: The multi-arch implementation website does not say anything about include directories. But I do have a /usr/include/x86_64-linux-gnu/ directory on my machine. And this makes sense because some include files depend on the architecture. Since base needs some of them (like sys/stat.h) you have to include this directory as well. But this should be done by the compiler automatically. That's why at least a build for linux on linux works without any changes :-)

You are right, the most important change is the install location of the EPICS libraries. But to build the same package on squeeze and wheezy you need a reliable way to detect the correct path.

As far as I can see we have three options:

1. Commit a change to the epics-base Debian repository that follows the recommendations on the Debian multi-arch website [1]:

   Any occurrences of /usr/lib in debian/rules should be replaced with /usr/lib/$(DEB_HOST_MULTIARCH). If you needed to use $(DEB_HOST_MULTIARCH) in debian/rules in either of the two preceding steps, set DEB_HOST_MULTIARCH in debian/rules by calling: DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH).

   Unfortunately the dpkg-architecture call does not succeed on squeeze. Are we sure this concept works properly on squeeze? Note that this approach only fixes the issue for Debian. The problem will come up again and again if other distributions switch to multi-arch as well.

2. Do it right. Fix the upstream build system to always query the compiler/OS. See [2] for a discussion of some ways to do this.
3. Use another build tool like CMake for the Debian packages that does handle multi-arch out of the box. Right now I'm suggesting this for the Debian builds only - not as a replacement of the official build system. Let's start small on this...

I don't think cross-builds are OT here since the whole idea of multi-arch is about: a) executing binaries for different architectures on the same machine b) using libraries for different architectures for cross-builds (e.g. armhf on x86_64) To me Debian's ability to do clean cross-builds with multi-arch is one of the main reasons why I believe the EPICS community should go for Debian...

[1] https://wiki.debian.org/Multiarch/Implementation#dh.281.29_and_autotools [2] http://public.kitware.com/Bug/view.php?id=12037

[ralphlange]

My vote goes for option 1.

Issues

• squeeze compatibility
  squeeze does not support Multi-Arch, and, due to the changes in other debian/* files that are not makefile snippets, needs a backport anyway. As long as we support it, then the issue will disappear. Minor.
• other distributions
  This repository is about packaging EPICS Base on Debian for Debian (and relatives). Out of scope.
• change upstream build
  Interesting idea, but not applicable at this place. Should be discussed on core-talk instead. Out of scope.
• different build system for packaging
  Might create a support nightmare when packaging applications that use the EPICS system in a non-standard way. -1
• Debian Multi-Arch for EPICS cross builds
  Interesting idea, but not applicable at this place. Should be discussed on core-talk instead. Out of scope.

You do have a couple of good and valid points, no doubt. Please put them on core-talk for discussion.

I have packaged a 32bit application that I am not able to install without switching all EPICS packages to 32bit. This is my problem, and this is what I need to have solved today. All I need for this to work are the shared libraries in /usr/lib/${triplet}. I am not going to switch the build system to achieve this.

[mdavidsaver]

To summarize. It would be immediately useful for Ralph if the libepics* package were "Multi-Arch: same". More will be done, this is a first step. The only question is how to retain build compatibility with debian 6.x.

It is probably best to make dh_epics_installlibs smart enough to check for Multi-Arch support and put libraries in the correct directory. This will likely entail bypassing dh_install[1] and directly putting library files in the correct binary package instead of debian/tmp/.

As a bonus this will do most of the work of fixing all packages using epics-debhelper.

[1] when no .install file is present. This gives backwards compatibility.

[ralphlange]

Yup. That's what I started working on. (I did mean "today" literally.)

Thanks for the pointers!

[ralphlange]

Fixed in 3.14.12.3-7