[RTEMS Project] #3817: RSB fails on FreeBSD 12.0 (32bit and 64bit)

[RTEMS trac]

#3817: RSB fails on FreeBSD 12.0 (32bit and 64bit)
------------------------+--------------------------
 Reporter:  Jeff Mayes  |       Owner:  Chris Johns
     Type:  defect      |      Status:  assigned
 Priority:  normal      |   Milestone:  5.1
Component:  arch/arm    |     Version:  5
 Severity:  normal      |  Resolution:
 Keywords:              |  Blocked By:
 Blocking:              |
------------------------+--------------------------

Comment (by Chris Johns):

 Replying to [comment:12 Joel Sherrill]:
 > Replying to [comment:11 Chris Johns]:
 > > Replying to [comment:7 Joel Sherrill]:
 > > > Strangely, it looks like the autoconf tests must be passing to
 detect libiconv but when it comes time to link, the symbols aren't there.
 > > >
 > > > Do you know how to turn on verbose mode so the make shows the real
 commands? That might help some.
 > >
 > > The log contains all the command and if that is not enough detail try
 `--trace` (1)
 > >
 > > The log will show a shell script is created and I think that script is
 run with `set -x` which prints the commands. On a failed build the script
 is left in the build tree.
 > >
 >
 > The RSB isn't the problem here. It is the GDB build itself. They have
 gone to a quiet build which only prints something like "CCLD gdb" which
 isn't helpful at all.

 I am OK with that change. There is so much rubbish printed that is
 meaningless. Assuming `automake` I suggest you have a look at.

 https://www.gnu.org/software/automake/manual/html_node/Automake-Silent-
 Rules.html

 Try adding `V=1` to the `make` command line.

 > I think you mentioned that the main libiconv package may be broken and
 that there is another in ports. Is that correct?

 I am not sure it is broken, that depends on how it is used and the
 interfaces provided. Is this library part of a standard? If it is not then
 I would not use "broken".

 > If so, should the default one be removed and the ports one used?

 No, ports are added. FreeBSD provides the kernel and base user land as a
 release. This means a `libiconv` may be provided by the OS base if it is
 needed that is suitable for the base OS user land executables. A port is
 also provided so there may be differences other software such as `gdb`
 requires.

 I feel you are approaching the issue from a Linux point of view which is a
 kernel as a separate configuration item plus the distro's user land where
 all the user land is under `/usr` as one big and hopefully happy family.
 FreeBSD follows the historical (?) path of the kernel and base user land
 being a single controlled and released item and so you do not touch it.
 The benefit is the base OS is tested to work and if you do not touch it no
 matter what you install you can at least recover back to that base.

--
Ticket URL: <http://devel.rtems.org/ticket/3817#comment:13>
RTEMS Project <http://www.rtems.org/>
RTEMS Project