[RTEMS Project] #3817: RSB fails on FreeBSD 12.0 (32bit and 64bit)
trac at rtems.org
Thu Nov 7 22:39:43 UTC 2019
#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:
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
> > 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.
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`
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/>
More information about the bugs