Merge ~dirk.zimoch/epics-base:raspberryPi into ~epics-core/epics-base/+git/epics-base:7.0
- Git
- lp:~dirk.zimoch/epics-base
- raspberryPi
- Merge into 7.0
Status: | Rejected |
---|---|
Rejected by: | Andrew Johnson |
Proposed branch: | ~dirk.zimoch/epics-base:raspberryPi |
Merge into: | ~epics-core/epics-base/+git/epics-base:7.0 |
Diff against target: |
92 lines (+80/-0) 2 files modified
configure/os/CONFIG.Common.raspbian-arm (+11/-0) configure/os/CONFIG_SITE.Common.raspbian-arm (+69/-0) |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Andrew Johnson | Disapprove | ||
mdavidsaver | Disapprove | ||
Review via email: mp+367256@code.launchpad.net |
Commit message
Description of the change
Configuration file for raspberryPi added.
mdavidsaver (mdavidsaver) wrote : | # |
mdavidsaver (mdavidsaver) wrote : | # |
I hadn't come across https:/
Judging by the (3 year old) commit message, these binaries are from a crosstool-ng built, not the native raspbian. ABI mis-matches with the raspian toolchain are to be expected.
fyi. seeing linking issues involving libtinfo.so is a sign of mixing debian and non-debian builds of readline.
If you use this toolchain then imo. full static linking (including libc) is a must!
If interop with raspbian libs is desirable, then I'd suggest looking at QEMU user mode emulation to run the hosted toolchain.
Dirk Zimoch (dirk.zimoch) wrote : | # |
> Do you have references to upstream bug reports?
>
> I've never encountered problems like this with the hosted compiler.
What problem? This is no bugfix. I just wanted to share my setup to cross-compile for raspberryPi. Maybe it is useful for others wanting to use EPICS on a pi.
Dirk Zimoch (dirk.zimoch) wrote : | # |
> I hadn't come across https:/
> seen it, I don't think I would ever use it!
>
> Judging by the (3 year old) commit message, these binaries are from a
> crosstool-ng built, not the native raspbian. ABI mis-matches with the raspian
> toolchain are to be expected.
There is a comment about readline in the file.
>
> fyi. seeing linking issues involving libtinfo.so is a sign of mixing debian
> and non-debian builds of readline.
>
> If you use this toolchain then imo. full static linking (including libc) is a
> must!
>
> If interop with raspbian libs is desirable, then I'd suggest looking at QEMU
> user mode emulation to run the hosted toolchain.
>
> https:/
This was the "official" cross tool chain, AFAIK.
Andrew Johnson (anj) wrote : | # |
Is this configuration intended for cross-building? Have you used it for building native as well?
The EPICS build system was designed so that end-users should never have to modify any CONFIG.* files to build Base, they should only edit CONFIG_SITE.* files, so your SDK_TARGET value should get in a CONFIG_SITE.* file. If this configuration is used for cross-building only then it really belongs in a CONFIG_
I have asked Pete Jemian who has lots of experience with running EPICS on the Pi for his comments too.
Andrew Johnson (anj) wrote : | # |
There seem to be a number of possibilities for Raspbian cross-building, the various answers to the stack-overflow question at https:/
There is also a post on Medium at https:/
Dirk Zimoch (dirk.zimoch) wrote : | # |
> Is this configuration intended for cross-building? Have you used it for
> building native as well?
This is for cross build. Native builds do not need to care for SDK locations. But I like to cross build for all our archs.
> The EPICS build system was designed so that end-users should never have to
> modify any CONFIG.* files to build Base, they should only edit CONFIG_SITE.*
> files, so your SDK_TARGET value should get in a CONFIG_SITE.* file. If this
> configuration is used for cross-building only then it really belongs in a
> CONFIG_
> files are for things that really are specific to the target irrespective of
> where the code is being compiled.
This is simply how I got it working. I‘ll try to separate it into user config and generic settings.
>
> I have asked Pete Jemian who has lots of experience with running EPICS on the
> Pi for his comments too.
Dirk Zimoch (dirk.zimoch) wrote : | # |
> There seem to be a number of possibilities for Raspbian cross-building, the
> various answers to the stack-overflow question at
> https:/
> cross-compiler-
> chain that Dirk is using does seem to be the "official" one. A fairly
> comprehensive alternative set with more recent versions is available at
> https:/
>
> There is also a post on Medium at https:/
> raspberrypi-
> issues using the official tool-chain, but it's configuring application builds
> using CMAKE and I haven't looked at it in detail.
I‘ll try to support them as well. I had stopped looking for alternatives once I had a working solution.
Dirk Zimoch (dirk.zimoch) wrote : | # |
I tried cross-pi-
Dirk Zimoch (dirk.zimoch) wrote : | # |
I could build from cross-pi-
- 56a4bb5... by Dirk Zimoch
-
moved user configuration to CONFIG_SITE file and support cross-pi-gcc tool chain
mdavidsaver (mdavidsaver) wrote : | # |
> There seem to be a number of possibilities for Raspbian cross-building
Actually, there are few options for cross-compiling for Raspbian. I'm specifically referring to the Debian derived distro. Raspbian doesn't provide any "official" cross-compiler binaries. Variations on the qemu-user approach are the only ones I would expect to produce guaranteed ABI compatible binaries. There are docker/lxc approaches which might be more palatable than the manual chroot() recipe I linked.
If you aren't willing/able to use qemu-user, then I would advising using buildroot to replace the raspbian image entirely.
When evaluating a particular recipe. Look for mentions of a specific Raspbian release name/version, or copying from a live Pi. Anything else is likely to be a variation on crosstool-ng, and have the same ABI issues you've encountered.
mdavidsaver (mdavidsaver) wrote : | # |
Maybe a wiki page or blog post would be a more appropriate place to document this build recipe?
Andrew Johnson (anj) wrote : | # |
I heard back from Pete Jemian, who wrote:
-------
Agree that Dirk references the official RPi tools for cross-compile. I have very little experience with getting that tool chain to work and only rely on native builds for EPICS base. (Those are easy and do not require any custom files.) The abhiTronix/
The proposed changes benefit those who use cross-compilers for the RPi. If merged, the changes should not affect native builds.
-------
I like Michael's suggestion that a lot of this information might make more sense as a Wiki, blog or tech-talk post. Updating it then wouldn't have to synchronize with Base releases.
You might also consider splitting your CONFIG_SITE file into CONFIG_
Dirk Zimoch (dirk.zimoch) wrote : | # |
The 32 bit tool chains work on 64 bit hosts as well (as long as 32 bit libs are installed).
Much here depends on the host. I have tried to hive as much information as possible that the user has a choice. I doubt that it is possible to split the configuration in way that makes it more easy to get the correct settings. It only makes information harder to find.
Any suggestions as to where the documentation may go? I found something here: http://
I can add an article to https:/
Dirk Zimoch (dirk.zimoch) wrote : | # |
Seems I already had an account for the EPICS wiki.
mdavidsaver (mdavidsaver) wrote : | # |
I still don't think that configure/ is the right place to document this recipe.
Also, I dusted off my pi3 and tried a buildroot image. It worked on the first go.
https:/
Andrew Johnson (anj) wrote : | # |
Group 10/4: Disapprove this solution.
Unmerged commits
- 56a4bb5... by Dirk Zimoch
-
moved user configuration to CONFIG_SITE file and support cross-pi-gcc tool chain
- 9866f3e... by Dirk Zimoch
-
support for raspberryPi addedconfigure/
os/CONFIG. Common. raspbian- arm
Preview Diff
1 | diff --git a/configure/os/CONFIG.Common.raspbian-arm b/configure/os/CONFIG.Common.raspbian-arm |
2 | new file mode 100644 |
3 | index 0000000..206d984 |
4 | --- /dev/null |
5 | +++ b/configure/os/CONFIG.Common.raspbian-arm |
6 | @@ -0,0 +1,11 @@ |
7 | +# CONFIG.Common.raspbian-arm |
8 | +# |
9 | +# Definitions for raspbian-arm target cross-builds |
10 | +# Override these settings in CONFIG_SITE.Common.raspbian-arm |
11 | +#------------------------------------------------------- |
12 | + |
13 | +# Include definitions common to all Linux ARM targets |
14 | +include $(CONFIG)/os/CONFIG.Common.linux-arm |
15 | + |
16 | +GNU_DIR = $(if $(filter %/arm-bcm2708,$(SDK_DIR)),$(SDK_DIR)/$(SDK_TARGET),$(SDK_DIR)) |
17 | +GNU_TARGET = $(if $(filter arm-bcm2708%,$(SDK_TARGET)),$(SDK_TARGET),arm-linux-gnueabihf) |
18 | diff --git a/configure/os/CONFIG_SITE.Common.raspbian-arm b/configure/os/CONFIG_SITE.Common.raspbian-arm |
19 | new file mode 100644 |
20 | index 0000000..e7fddc3 |
21 | --- /dev/null |
22 | +++ b/configure/os/CONFIG_SITE.Common.raspbian-arm |
23 | @@ -0,0 +1,69 @@ |
24 | +# CONFIG_SITE.Common.raspbian-arm |
25 | +# |
26 | +# Site-specific information for raspbian-arm target cross-builds |
27 | +#--------------------------------------------------------------- |
28 | + |
29 | +# Tested on: |
30 | +# Raspberry Pi 3B+ Raspbian 9 |
31 | +# Raspberry Pi 2 Raspbian 7 |
32 | + |
33 | +# Two different cross tool chains are supported, |
34 | +# either from https://github.com/raspberrypi/tools |
35 | +# (the "arm-bcm2708" tool chain) |
36 | +# or from https://sourceforge.net/projects/raspberry-pi-cross-compilers. |
37 | +# (the "cross-pi-gcc" tool chain). |
38 | + |
39 | +# Using the arm-bcm2708 tool chain. |
40 | +# |
41 | +# This tool chains offers 5 different pre-compiled targets. Which one |
42 | +# can be used depends on the glibc version installed on the host computer. |
43 | +# |
44 | +# Can be installed anywhere, e.g: |
45 | +SDK_DIR = /opt/raspberrypi/tools-master/arm-bcm2708 |
46 | +# |
47 | +# Available SDK_TARGETs for arm-bcm2708 SDK: |
48 | +# |
49 | +# gcc 4.8.3 for 32 bit hosts with GLIBC 2.3 or higher |
50 | +SDK_TARGET = gcc-linaro-arm-linux-gnueabihf-raspbian |
51 | +# |
52 | +# gcc 4.7.1 for 64 bit hosts with GLIBC 2.14 or higher |
53 | +# SDK_TARGET = arm-linux-gnueabihf |
54 | +# |
55 | +# gcc 4.8.3 for 64 bit hosts with GLIBC 2.14 or higher |
56 | +# SDK_TARGET = gcc-linaro-arm-linux-gnueabihf-raspbian-x64 |
57 | +# |
58 | +# gcc 4.7.1 for 32 bit hosts with GLIBC 2.4 or higher |
59 | +# SDK_TARGET = arm-bcm2708hardfp-linux-gnueabi |
60 | +# SDK_TARGET = arm-bcm2708-linux-gnueabi |
61 | + |
62 | + |
63 | +# Using the cross-pi-gcc tool chain. |
64 | +# |
65 | +# gcc 8.3.0 for 64 bit hosts with GLIBC 2.14 or higher. |
66 | +# Must be installed at the following location: |
67 | +# SDK_DIR = /opt/cross-pi-gcc-8.3.0-1 |
68 | + |
69 | + |
70 | +# Using readline: |
71 | +# |
72 | +# Due to missing/messed up libs and missing headers in both toolchains, |
73 | +# readline needs copies of libtinfo.so.5.9 and libreadline.so.6.2 from |
74 | +# a Raspbian 7 rootfs /lib/arm-linux-gnueabihf/ to the toolchain, e.g. |
75 | +# $(SDK_DIR)/gcc-linaro-arm-linux-gnueabihf-raspbian/arm-linux-gnueabihf/libc/lib/arm-linux-gnueabihf/ |
76 | +# or /opt/cross-pi-gcc-8.3.0-1/arm-linux-gnueabihf/lib/, depending on |
77 | +# the used toolchain, and manually created links libtinfo.so.5 and libreadline.so. |
78 | +# |
79 | +# For SDK_TARGET gcc-linaro-arm-linux-gnueabihf-raspbian, an existing incompatible |
80 | +# libtinfo.so.5 is in the way. Remove it. |
81 | +# (Built with glibc 2.16 like installed on Raspbian 9 but toolchain uses glibc 2.13.) |
82 | +# |
83 | +# The cross-pi-gcc toolchain is also missing libtinfo.so* as well. Copy the file and links |
84 | +# from /lib/arm-linux-gnueabihf/ to /opt/cross-pi-gcc-8.3.0-1/arm-linux-gnueabihf/lib/. |
85 | +# |
86 | +# Also copy the /usr/include/readline/ directory from some readline 6 installation |
87 | +# to $(SDK_DIR)/gcc-linaro-arm-linux-gnueabihf-raspbian/arm-linux-gnueabihf/libc/usr/include/ |
88 | +# or /opt/cross-pi-gcc-8.3.0-1/arm-linux-gnueabihf/include/, depending on the |
89 | +# used toolchain. |
90 | +# |
91 | +# Once the above fixes are applied, uncomment the next line. |
92 | +# COMMANDLINE_LIBRARY = READLINE |
Do you have references to upstream bug reports?
I've never encountered problems like this with the hosted compiler.