summaryrefslogtreecommitdiffstats
path: root/meta/recipes-connectivity
diff options
context:
space:
mode:
authorTom Rini <trini@konsulko.com>2019-03-12 16:07:21 -0400
committerRichard Purdie <richard.purdie@linuxfoundation.org>2019-03-18 11:09:55 +0000
commit4bd1a09c47de49d78cc85d849e53d4661831870b (patch)
treea6e1d5dbb0a78afeab254466710489fdbb616345 /meta/recipes-connectivity
parent314a1b64a629cf072ceb12925518ceac8beea126 (diff)
downloadopenembedded-core-4bd1a09c47de49d78cc85d849e53d4661831870b.tar.gz
inetutils: Handle rsh, etc more consistently
- We cannot build rsh, rshd, rlogind and rcp on musl. This is handled gracefully in the configure scripts and spelled out with EXTRA_OECONF. Expand this to include rexec to cover all of the related functionality. - Rework adding in the xinetd.d files for these services to only do so when we even have the services being built. This leads to no rsh/rshd sub-packages on musl at all. - If we use the normal alternatives mechanism to allow for this or netkit-rsh to provide rsh/rshd functionality we end up with QA issues on musl as we have unused ALTERNATIVES logic. Switch to making use of RPROVIDES / RCONFLICTS logic instead and make it match the netkit-rsh packaging names. Cc: Khem Raj <raj.khem@gmail.com> Signed-off-by: Tom Rini <trini@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-connectivity')
-rw-r--r--meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb32
1 files changed, 16 insertions, 16 deletions
diff --git a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
index 9318d12309..4aa350947a 100644
--- a/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
+++ b/meta/recipes-connectivity/inetutils/inetutils_1.9.4.bb
@@ -49,7 +49,7 @@ EXTRA_OECONF = "--with-ncurses-include-dir=${STAGING_INCDIR} \
--enable-rpath=no \
"
-EXTRA_OECONF_append_libc-musl = " --disable-rsh --disable-rcp --disable-rlogin "
+EXTRA_OECONF_append_libc-musl = " --disable-rsh --disable-rcp --disable-rlogin --disable-rexec --disable-rexecd"
do_configure_prepend () {
export HELP2MAN='true'
@@ -72,21 +72,23 @@ do_install_append () {
mv ${D}${libexecdir}/syslogd ${D}${base_sbindir}/
mv ${D}${libexecdir}/tftpd ${D}${sbindir}/in.tftpd
mv ${D}${libexecdir}/telnetd ${D}${sbindir}/in.telnetd
- mv ${D}${libexecdir}/rexecd ${D}${sbindir}/in.rexecd
+ if [ -e ${D}${libexecdir}/rexecd ]; then
+ mv ${D}${libexecdir}/rexecd ${D}${sbindir}/in.rexecd
+ cp ${WORKDIR}/rexec.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rexec
+ fi
if [ -e ${D}${libexecdir}/rlogind ]; then
mv ${D}${libexecdir}/rlogind ${D}${sbindir}/in.rlogind
+ cp ${WORKDIR}/rlogin.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rlogin
fi
if [ -e ${D}${libexecdir}/rshd ]; then
mv ${D}${libexecdir}/rshd ${D}${sbindir}/in.rshd
+ cp ${WORKDIR}/rsh.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rsh
fi
if [ -e ${D}${libexecdir}/talkd ]; then
mv ${D}${libexecdir}/talkd ${D}${sbindir}/in.talkd
fi
mv ${D}${libexecdir}/uucpd ${D}${sbindir}/in.uucpd
mv ${D}${libexecdir}/* ${D}${bindir}/
- cp ${WORKDIR}/rexec.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rexec
- cp ${WORKDIR}/rlogin.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rlogin
- cp ${WORKDIR}/rsh.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/rsh
cp ${WORKDIR}/telnet.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/telnet
cp ${WORKDIR}/tftpd.xinetd.inetutils ${D}/${sysconfdir}/xinetd.d/tftpd
@@ -132,15 +134,6 @@ ALTERNATIVE_${PN}-telnetd = "telnetd"
ALTERNATIVE_LINK_NAME[telnetd] = "${sbindir}/telnetd"
ALTERNATIVE_TARGET[telnetd] = "${sbindir}/in.telnetd"
-ALTERNATIVE_${PN}-rsh = "rcp rexec rlogin rsh"
-ALTERNATIVE_${PN}-rshd = "rshd rexecd rlogind"
-ALTERNATIVE_LINK_NAME[rshd] = "${sbindir}/rshd"
-ALTERNATIVE_TARGET[rshd] = "${sbindir}/in.rshd"
-ALTERNATIVE_LINK_NAME[rexecd] = "${sbindir}/rexecd"
-ALTERNATIVE_TARGET[rexecd] = "${sbindir}/in.rexecd"
-ALTERNATIVE_LINK_NAME[rlogind] = "${sbindir}/rlogind"
-ALTERNATIVE_TARGET[rlogind] = "${sbindir}/in.rlogind"
-
ALTERNATIVE_${PN}-inetd= "inetd"
ALTERNATIVE_${PN}-traceroute = "traceroute"
@@ -178,13 +171,20 @@ FILES_${PN}-ftp = "${bindir}/ftp.${BPN}"
FILES_${PN}-tftp = "${bindir}/tftp.${BPN}"
FILES_${PN}-telnet = "${bindir}/telnet.${BPN}"
-FILES_${PN}-rsh = "${bindir}/rsh.${BPN} ${bindir}/rlogin.${BPN} ${bindir}/rexec.${BPN} ${bindir}/rcp.${BPN}"
+
+# We make us of RCONFLICTS / RPROVIDES here rather than using the normal
+# alternatives method as this leads to packaging QA issues when using
+# musl as that library does not provide what these applications need to
+# build.
+FILES_${PN}-rsh = "${bindir}/rsh ${bindir}/rlogin ${bindir}/rexec ${bindir}/rcp"
+RCONFLICTS_${PN}-rsh += "netkit-rsh-client"
+RPROVIDES_${PN}-rsh = "rsh"
FILES_${PN}-rshd = "${sbindir}/in.rshd ${sbindir}/in.rlogind ${sbindir}/in.rexecd \
${sysconfdir}/xinetd.d/rsh ${sysconfdir}/xinetd.d/rlogin ${sysconfdir}/xinetd.d/rexec"
FILES_${PN}-rshd-dbg = "${sbindir}/.debug/in.rshd ${sbindir}/.debug/in.rlogind ${sbindir}/.debug/in.rexecd"
RDEPENDS_${PN}-rshd += "xinetd tcp-wrappers"
-RCONFLICTS_${PN}-rshd += "netkit-rshd"
+RCONFLICTS_${PN}-rshd += "netkit-rshd-server"
RPROVIDES_${PN}-rshd = "rshd"
FILES_${PN}-ftpd = "${bindir}/ftpd.${BPN}"
km/systemd OpenEmbedded Core user contribution treesGrokmirror user
summaryrefslogtreecommitdiffstats
path: root/documentation/sdk-manual/sdk-appendix-obtain.xml
blob: d0cbf9c85ec29a1fa060127dc26714093660ee25 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >

<appendix id='sdk-appendix-obtain'>

<title>Obtaining the SDK</title>

<section id='sdk-locating-pre-built-sdk-installers'>
    <title>Locating Pre-Built SDK Installers</title>

    <para>
        You can use existing, pre-built toolchains by locating and running
        an SDK installer script that ships with the Yocto Project.
        Using this method, you select and download an architecture-specific
        SDK installer and then run the script to hand-install the
        toolchain.
    </para>

    <para>
        You can find SDK installers here:
        <itemizedlist>
            <listitem><para><emphasis>Standard SDK Installers:</emphasis>
                Go to <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
                and find the folder that matches your host development system
                (i.e. <filename>i686</filename> for 32-bit machines or
                <filename>x86_64</filename> for 64-bit machines).</para>

                <para>Go into that folder and download the SDK installer
                whose name includes the appropriate target architecture.
                The toolchains provided by the Yocto Project are based off of
                the <filename>core-image-sato</filename> image and contain
                libraries appropriate for developing against that image.
                For example, if your host development system is a 64-bit x86
                system and you are going to use your cross-toolchain for a
                32-bit x86 target, go into the <filename>x86_64</filename>
                folder and download the following installer:
                <literallayout class='monospaced'>
     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                </literallayout>
                </para></listitem>
            <listitem><para><emphasis>Extensible SDK Installers:</emphasis>
                Installers for the extensible SDK are also located in
                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
                These installers have the string
                <filename>ext</filename> as part of their names:
                <literallayout class='monospaced'>
     poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
                </literallayout>
                </para></listitem>
        </itemizedlist>
    </para>
</section>

<section id='sdk-building-an-sdk-installer'>
    <title>Building an SDK Installer</title>

    <para>
        As an alternative to locating and downloading a SDK installer,
        you can build the SDK installer assuming you have first sourced
        the environment setup script.
        See the
        "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
        section in the Yocto Project Quick Start for steps that show you
        how to set up the Yocto Project environment.
        In particular, you need to be sure the
        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
        variable matches the architecture for which you are building and that
        the
        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
        variable is correctly set if you are building a toolchain designed to
        run on an architecture that differs from your current development host
        machine (i.e. the build machine).
    </para>

    <para>
        To build the SDK installer for a standard SDK and populate
        the SDK image, use the following command:
        <literallayout class='monospaced'>
     $ bitbake <replaceable>image</replaceable> -c populate_sdk
        </literallayout>
        You can do the same for the extensible SDK using this command:
        <literallayout class='monospaced'>
     $ bitbake <replaceable>image</replaceable> -c populate_sdk_ext
        </literallayout>
        These commands result in a SDK installer that contains the sysroot
        that matches your target root filesystem.
    </para>

    <para>
        When the <filename>bitbake</filename> command completes, the SDK
        installer will be in
        <filename>tmp/deploy/sdk</filename> in the Build Directory.
        <note><title>Notes</title>
            <itemizedlist>
                <listitem><para>
                    By default, this toolchain does not build static binaries.
                    If you want to use the toolchain to build these types of
                    libraries, you need to be sure your SDK has the
                    appropriate static development libraries.
                    Use the
                    <ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></ulink>
                    variable inside your <filename>local.conf</filename> file
                    to install the appropriate library packages in the SDK.
                    Following is an example using <filename>libc</filename>
                    static development libraries:
                    <literallayout class='monospaced'>
     TOOLCHAIN_TARGET_TASK_append = " libc-staticdev"
                    </literallayout>
                    </para></listitem>
                <listitem><para>
                    For additional information on building the installer,
                    see the
                    <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink>
                    wiki page.
                    </para></listitem>
            </itemizedlist>
        </note>
    </para>
</section>

<section id='sdk-extracting-the-root-filesystem'>
    <title>Extracting the Root Filesystem</title>

    <para>
        After installing the toolchain, for some use cases you
        might need to separately extract a root filesystem:
        <itemizedlist>
            <listitem><para>You want to boot the image using NFS.
                </para></listitem>
            <listitem><para>You want to use the root filesystem as the
                target sysroot.
                For example, the Eclipse IDE environment with the Eclipse
                Yocto Plug-in installed allows you to use QEMU to boot
                under NFS.</para></listitem>
            <listitem><para>You want to develop your target application
                using the root filesystem as the target sysroot.
                </para></listitem>
        </itemizedlist>
    </para>

    <para>
        To extract the root filesystem, first <filename>source</filename>
        the cross-development environment setup script to establish
        necessary environment variables.
        If you built the toolchain in the Build Directory, you will find
        the toolchain environment script in the
        <filename>tmp</filename> directory.
        If you installed the toolchain by hand, the environment setup
        script is located in <filename>/opt/poky/&DISTRO;</filename>.
    </para>

    <para>
        After sourcing the environment script, use the
        <filename>runqemu-extract-sdk</filename> command and provide the
        filesystem image.
    </para>

    <para>
        Following is an example.
        The second command sets up the environment.
        In this case, the setup script is located in the
        <filename>/opt/poky/&DISTRO;</filename> directory.
        The third command extracts the root filesystem from a previously
        built filesystem that is located in the
        <filename>~/Downloads</filename> directory.
        Furthermore, this command extracts the root filesystem into the
        <filename>qemux86-sato</filename> directory:
        <literallayout class='monospaced'>
     $ cd ~
     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
     $ runqemu-extract-sdk \
        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
        $HOME/qemux86-sato
        </literallayout>
        You could now point to the target sysroot at
        <filename>qemux86-sato</filename>.
    </para>
</section>

<section id='sdk-installed-standard-sdk-directory-structure'>
    <title>Installed Standard SDK Directory Structure</title>

    <para>
        The following figure shows the resulting directory structure after
        you install the Standard SDK by running the <filename>*.sh</filename>
        SDK installation script:
    </para>

    <para>
        <imagedata fileref="figures/sdk-installed-standard-sdk-directory.png" scale="60" align="center" />
    </para>

    <para>
        The installed SDK consists of an environment setup script for the SDK,
        a configuration file for the target, a version file for the target,
        and the root filesystem (<filename>sysroots</filename>) needed to
        develop objects for the target system.
    </para>

    <para>
        Within the figure, italicized text is used to indicate replaceable
        portions of the file or directory name.
        For example,
        <replaceable>install_dir</replaceable>/<replaceable>version</replaceable>
        is the directory where the SDK is installed.
        By default, this directory is <filename>/opt/poky/</filename>.
        And, <replaceable>version</replaceable> represents the specific
        snapshot of the SDK (e.g. <filename>&DISTRO;</filename>).
        Furthermore, <replaceable>target</replaceable> represents the target
        architecture (e.g. <filename>i586</filename>) and
        <replaceable>host</replaceable> represents the development system's
        architecture (e.g. <filename>x86_64</filename>).
        Thus, the complete names of the two directories within the
        <filename>sysroots</filename> could be
        <filename>i586-poky-linux</filename> and
        <filename>x86_64-pokysdk-linux</filename> for the target and host,
        respectively.
    </para>
</section>

<section id='sdk-installed-extensible-sdk-directory-structure'>
    <title>Installed Extensible SDK Directory Structure</title>

    <para>
        The following figure shows the resulting directory structure after
        you install the Extensible SDK by running the <filename>*.sh</filename>
        SDK installation script:
    </para>

    <para>
        <imagedata fileref="figures/sdk-installed-extensible-sdk-directory.png" scale="60" align="center" />
    </para>

    <para>
        The installed directory structure for the extensible SDK is quite
        different than the installed structure for the standard SDK.
        The extensible SDK does not separate host and target parts in the
        same manner as does the standard SDK.
        The extensible SDK uses an embedded copy of the OpenEmbedded
        build system, which has its own sysroots.
    </para>

    <para>
        Of note in the directory structure are an environment setup script
        for the SDK, a configuration file for the target, a version file for
        the target, and a log file for the OpenEmbedded build system
        preparation script run by the installer.
    </para>

    <para>
        Within the figure, italicized text is used to indicate replaceable
        portions of the file or directory name.
        For example,
        <replaceable>install_dir</replaceable> is the directory where the SDK
        is installed, which is <filename>poky_sdk</filename> by default.
        <replaceable>target</replaceable> represents the target
        architecture (e.g. <filename>i586</filename>) and
        <replaceable>host</replaceable> represents the development system's
        architecture (e.g. <filename>x86_64</filename>).
    </para>
</section>

</appendix>
<!--
vim: expandtab tw=80 ts=4
-->