Link errors with an install using quick-start guide

Chris Johns chrisj at rtems.org
Thu Jul 25 22:06:12 UTC 2019


On 26/7/19 5:22 am, Sebastian Huber wrote:
> ----- Am 25. Jul 2019 um 21:19 schrieb joel joel at rtems.org:
> 
>> On Thu, Jul 25, 2019 at 2:13 PM Sebastian Huber <
>> sebastian.huber at embedded-brains.de> wrote:
>>
>>> ----- Am 25. Jul 2019 um 20:59 schrieb joel joel at rtems.org:
>>>
>>>> Having a separate library for rtems default configuration breaks autoconf
>>>> probes for packages which are built using BSP specific arguments. These
>>>> have built the same way for well over a decade.
>>>>
>>>> I know this can be resolved by passing in an extra library on the
>>> configure
>>>> line. But this broke a public behavior in an undesirable and subtle way.
>>>
>>> I think we have to make a trade-off between difficult to figure out
>>> configuration issues which normally need the help of a linker map file (I
>>> don't think the average user knows what this is) and an extra option for
>>> already complicated Autoconf invocations.
>>>
>>
>> Is there any documentation on this flag and how it might be needed?
>>

I could not find any. I recently sorted this out with the BSP package build
patch to the RSB. It is not straight forward and time consuming.

>> I am not suggesting changing this -- just stating that it had a visible
>> side-effect that I don't recall getting the discussion that publicly
>> visible behavior changes should get.
> 
> Maybe a section in the user manual which explains
> 
> 1. which Autoconf stuff you need to build a multilib based configuration, and

I do not follow what this means. A 3rd party library can only be built for a BSP
as this is the only installed instance of an RTEMS kernel you can have.

> 2. which Autoconf stuff you need to build a BSP based configuration.

It is complicated and delicate because autoconf packages are not always
consistent in the their handling of flags and options and if libtool is used it
can be another layer of complexity.

The RSB contains all you need to get going and is the best example we currently
have. Here is a summary ...

Building a 3rd party library requires you set the host using --host, eg
--host=arm-rtems5. You need to set the build *and* host flags. The target can be
ignored as this is only used for compilers and the RTEMS kernel.

A working fragment of shell logic is in the RSB ...

https://git.rtems.org/rtems-source-builder/tree/source-builder/defaults.mc#n331

It is used before the configure command to provide the needs tools, flags and
libraries, eg to build the curl package ...

https://git.rtems.org/rtems-source-builder/tree/source-builder/config/curl-1.cfg#n49

Note,
- curl builds executables, ie curl, however I doubt it would run or be useful as
'-lrtemsdefaultconfig' is not a real configuration, it is just a stub so
executables can link.

RTEMS is a cross build so the "%build != host" logic is used and this defines
the following environment variables ...

  # Cross build
  CC = host_cc
  CXX = host_cxx
  CPPFLAGS = HOST_CPPFLAGS
  CFLAGS = HOST_CFLAGS
  CXXFLAGS = HOST_CXXFLAGS
  LDFLAGS = HOST_LDFLAGS
  LIBS = HOST_LIBS
  # Host
  CPPFLAGS_FOR_HOST = HOST_CPPFLAGS
  CFLAGS_FOR_HOST = HOST_CFLAGS
  CXXFLAGS_FOR_HOST = HOST_CXXFLAGS
  LDFLAGS_FOR_HOST = HOST_LDFLAGS
  LIBS_FOR_HOST = HOST_LIBS
  CC_FOR_HOST = host_cc HOST_CFLAGS}
  CXX_FOR_HOST = host_cxx HOST_CXXFLAGS
  # Build
  CFLAGS_FOR_BUILD = BUILD_CFLAGS
  CXXFLAGS_FOR_BUILD = BUILD_CXXFLAGS
  LDFLAGS_FOR_BUILD = BUILD_LDFLAGS
  LIBS_FOR_BUILD = BUILD_LIBS
  CXXFLAGS_FOR_BUILD = BUILD_CFLAGS
  CC_FOR_BUILD = __cc BUILD_CFLAGS
  CXX_FOR_BUILD = __cxx BUILD_CXXFLAGS

Note,
- remember to export the variables
- add '-lrtemsdefaultconfig' to HOST_LIBS so configure can link executables
- add '-lbsd -lm -lz' to HOST_LIBS for libbsd
- the RSB uses another more complex shell fragment to set the variables (line
207 of defaults.mc)

You need to make sure the CPP flags are defined and you need to be-careful where
the specs option is specified. The specs path option (-B) also provides a system
header path (yuck) but the specs can only appear once on a compiler command line
or gcc complains.

If you want to install the package using similar paths to an RTEMS BSP you need
to supply to configure all the needed paths correctly set, again the curl
example in the RSB ...

  ../${source_dir_curl}/configure \
    --host=%{_host} \
    --prefix=%{_prefix} \
    --bindir=%{_bindir} \
    --exec_prefix=%{_exec_prefix} \
    --includedir=%{_includedir} \
    --libdir=%{_libdir} \
    --libexecdir=%{_libexecdir} \
    --mandir=%{_mandir} \
    --infodir=%{_infodir} \
    --datadir=%{_datadir}

The next part is determining the values to place in these environment variables
and as paths, commands and flags. The RSB's RTEMS BSP config file does this ...

https://git.rtems.org/rtems-source-builder/tree/rtems/config/rtems-bsp.cfg

Note, the RSB support:
- handles the tools and RTEMS residing in the same or different directories
- staged builds, that is dependent package builds, you can ignore this

The path set up for a BSP in RSB config syntax is ...

%define rtems_bsp_prefix  %{_prefix}/%{_host}/%{rtems_bsp}
%define _exec_prefix      %{rtems_bsp_prefix}
%define _bindir           %{_exec_prefix}/bin
%define _sbindir          %{_exec_prefix}/sbin
%define _libexecdir       %{_exec_prefix}/libexec
%define _datarootdir      %{_exec_prefix}/share
%define _datadir          %{_datarootdir}
%define _sysconfdir       %{_exec_prefix}/etc
%define _sharedstatedir   %{_exec_prefix}/com
%define _localstatedir    %{_exec_prefix}/var
%define _includedir       %{_libdir}/include
%define _lib              lib
%define _libdir           %{_exec_prefix}/%{_lib}
%define _libexecdir       %{_exec_prefix}/libexec
%define _mandir           %{_datarootdir}/man
%define _infodir          %{_datarootdir}/info
%define _localedir        %{_datarootdir}/locale
%define _localedir        %{_datadir}/locale
%define _localstatedir    %{_exec_prefix}/var

where `_prefix` is the prefix the BSP is installed in, `_host` is something like
`arm-rtems5` and `rtems_bsp` is the BSP, eg `beagleboneblack`.

The RSB extracts the needed options from pkg-config ...

%define rtems_bsp_includes -I%{_includedir}
%define rtems_bsp_ccflags  %{pkgconfig ccflags %{_host}-%{rtems_bsp}}
%define rtems_bsp_cflags   %{pkgconfig cflags  %{_host}-%{rtems_bsp}}
%define rtems_bsp_ldflags  %{pkgconfig ldflags %{_host}-%{rtems_bsp}}
%define rtems_bsp_libs     %{pkgconfig libs    %{_host}-%{rtems_bsp}}

You can do this on a command line if pkg-config is installed ...

$ export PKG_CONFIG_PATH=/opt/work/chris/rtems/kernel/5/lib/pkgconfig
$ pkg-config --cflags arm-rtems5-beagleboneblack

Note,
- the RTEMS install prefix is /opt/work/chris/rtems/kernel/5

Our pkg-config support is limited so only --cflags is available. You can use
--print-variables to get at any other bits that may be useful.

The extracted BSP flags are turned into the host settings used to set the
environment variables for configure ...

%define host_cc       %{rtems_bsp_cc}
%define host_cxx      %{rtems_bsp_cxx}
%define host_includes %{rtems_bsp_includes}
%define host_cflags   %{rtems_bsp_cflags}
%define host_cxxflags %{rtems_bsp_ccflags}
%define host_ldflags  %{rtems_bsp_ldflags}
%define host_libs     %{rtems_bsp_libs}

Note, the RSB uses a BSP set of variables then the host variables to aid
debugging, it helps to see the various steps in a trace log.

I hope this helps.

Chris


More information about the users mailing list