#3817 assigned defect

RSB fails on FreeBSD 12.0 (32bit and 64bit)

Reported by: Jeff Mayes Owned by: Chris Johns
Priority: normal Milestone: 5.1
Component: arch/arm Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Chris Johns)

Fails to build GDB for both the Arm and Sparc architectures.

RTEMS Tools Project - Source Builder Error Report
 Build: error: building sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1
 Command Line: ../source-builder/sb-set-builder --prefix=/home/mayes/dev/rtems/5 5/rtems-sparc
 Python: 3.6.9 (default, Oct 24 2019, 01:18:01) [GCC 4.2.1 Compatible FreeBSD Clang 6.0.1 (tags/RELEASE_601/final 335540)]
 git://git.rtems.org/rtems-source-builder.git/origin/9a1cf9a2d940a4f79cd822f05c8fb13a4c0ec3bb
 FreeBSD rtbf64b 12.0-RELEASE-p10 FreeBSD 12.0-RELEASE-p10 GENERIC amd64

  CXXLD  gdb
/usr/bin/ld: error: undefined symbol: libiconv_open
>>> referenced by charset.c
>>>               charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))

/usr/bin/ld: error: undefined symbol: libiconv
>>> referenced by charset.c
>>>               charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))

/usr/bin/ld: error: undefined symbol: libiconv_close
>>> referenced by charset.c
>>>               charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))

/usr/bin/ld: error: undefined symbol: libiconv_close
>>> referenced by charset.c
>>>               charset.o:(convert_between_encodings(char const*, char const*, unsigned char const*, unsigned int, int, obstack*, transliterations))

/usr/bin/ld: error: undefined symbol: libiconv_open
>>> referenced by charset.c
>>>               charset.o:(wchar_iterator::wchar_iterator(unsigned char const*, unsigned long, char const*, unsigned long))

/usr/bin/ld: error: undefined symbol: libiconv_close
>>> referenced by charset.c
>>>               charset.o:(wchar_iterator::~wchar_iterator())

/usr/bin/ld: error: undefined symbol: libiconv_close
>>> referenced by charset.c
>>>               charset.o:(validate(gdbarch*))
c++: error: linker command failed with exit code 1 (use -v to see invocation)
gmake[2]: *** [Makefile:1889: gdb] Error 1
gmake[2]: Leaving directory '/usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/build/gdb'
gmake[1]: *** [Makefile:8792: all-gdb] Error 2
gmake[1]: Leaving directory '/usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/build'
gmake: *** [Makefile:849: all] Error 2
shell cmd failed: /bin/sh -ex  /usr/home/mayes/dev/rsb/rtems/build/sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1/do-build
error: building sparc-rtems5-gdb-8.3-x86_64-freebsd12.0-1

Change History (13)

comment:1 Changed on Nov 5, 2019 at 11:34:10 PM by Chris Johns

Description: modified (diff)
Milestone: 5.1

comment:2 Changed on Nov 6, 2019 at 10:26:42 AM by Sebastian Huber

I was able to build the RTEMS 5 tools with 12.0-RELEASE-p2. I will try to update to the latest FreeBSD 12 and see what happens.

comment:3 in reply to:  2 Changed on Nov 6, 2019 at 2:35:01 PM by Joel Sherrill

Replying to Sebastian Huber:

I was able to build the RTEMS 5 tools with 12.0-RELEASE-p2. I will try to update to the latest FreeBSD 12 and see what happens.

This is with a fresh install from their images. Jeff can give you the URL if it matters. Hopefully, there is something stupid on our side and not a difference between FreeBSD pre-release images and the final release image.

comment:4 Changed on Nov 6, 2019 at 2:38:09 PM by Sebastian Huber

I did an update to FreeBSD 12.1 and at least ARM is building fine:

https://lists.rtems.org/pipermail/build/2019-November/008065.html

comment:5 Changed on Nov 6, 2019 at 9:37:59 PM by Chris Johns

Do you have libiconv installed?

$ pkg which /usr/local/lib/libiconv.a                                                                                                                                                                                                                                                                                                             
/usr/local/lib/libiconv.a was installed by package libiconv-1.14_11

comment:6 Changed on Nov 7, 2019 at 6:00:10 AM by Sebastian Huber

Yes, I have the same output. We installed the following packages:

pkg install git
pkg install python
pkg install bison
pkg install gmake
pkg install subversion
pkg install makeinfo
pkg install texinfo
Last edited on Nov 7, 2019 at 6:00:32 AM by Sebastian Huber (previous) (diff)

comment:7 Changed on Nov 7, 2019 at 1:46:24 PM by 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.

comment:8 Changed on Nov 7, 2019 at 3:04:17 PM by Jeff Mayes

I updated to FreeBSD 12.1 yesterday, but it still fails the same way.

Yes, I have libiconv installed, same version shown above.

However, I didn't have subversion or makeinfo installed. Just installed subversion, so I'll try again and report back. What's up with makeinfo?

# pkg install makeinfo
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
pkg: No packages available to install matching 'makeinfo' have been found in the repositories
Last edited on Nov 7, 2019 at 9:33:45 PM by Chris Johns (previous) (diff)

comment:9 Changed on Nov 7, 2019 at 4:22:39 PM by Jeff Mayes

Still fails after subversion install, unsurprisingly.

Does this look correct? I excluded matches in /home directories.

# find / -name "libiconv*"
/usr/ports/converters/libiconv
/usr/lib/i18n/libiconv_std.so.4
/usr/lib/i18n/libiconv_none.so
/usr/lib/i18n/libiconv_std.so
/usr/lib/i18n/libiconv_none.so.4
/usr/lib/debug/boot/kernel/libiconv.ko.debug
/usr/local/share/licenses/libiconv-1.14_11
/usr/local/share/doc/libiconv
/usr/local/lib/libiconv.a
/usr/local/lib/libiconv.so.2
/usr/local/lib/libiconv.so.2.5.1
/usr/local/lib/libiconv.so
/usr/lib32/i18n/libiconv_none.so
/usr/lib32/i18n/libiconv_std.so.4
/usr/lib32/i18n/libiconv_std.so
/usr/lib32/i18n/libiconv_none.so.4
/boot/kernel/libiconv.ko
/boot/kernel.old/libiconv.ko
/var/cache/pkg/libiconv-1.14_11-1b77da9274.txz
/var/cache/pkg/libiconv-1.14_11.txz
Last edited on Nov 7, 2019 at 9:33:03 PM by Chris Johns (previous) (diff)

comment:10 in reply to:  9 Changed on Nov 7, 2019 at 9:29:46 PM by Chris Johns

Replying to Jeff Mayes:

Does this look correct? I excluded matches in /home directories.

# find / -name "libiconv*"
.. [snip] ...

FreeBSD makes a distinction between /usr and /usr/local. Anything under /usr excluding /usr/local is part of the base OS and you should not touch. Additional packages or ports are installed under /usr/local. If you look back at comment 5 by me you will see I have referenced a /usr/local path and not a /usr path like you have.

There are a couple of paths ...

  1. You need to check if you have the libiconv package installed as ask in comment 5. Maybe try pkg info | grep libiconv to see.
  1. When I originally added libiconv support for FreeBSD the OS versions of the libraries were not up to date and so the libiconv port was needed. The OS versions maybe suitable now, however at a guess I would say they are not as the build fails. You could look closely at the errors and OS provided library to know.

comment:11 in reply to:  7 ; Changed on Nov 7, 2019 at 9:32:40 PM by Chris Johns

Replying to 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.

(1) https://docs.rtems.org/branches/master/user/rsb/commands.html#set-builder-sb-set-builder

comment:12 in reply to:  11 ; Changed on Nov 7, 2019 at 10:04:58 PM by Joel Sherrill

Replying to Chris Johns:

Replying to 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 think you mentioned that the main libiconv package may be broken and that there is another in ports. Is that correct? If so, should the default one be removed and the ports one used?

comment:13 in reply to:  12 Changed on Nov 7, 2019 at 10:39:43 PM by Chris Johns

Replying to Joel Sherrill:

Replying to Chris Johns:

Replying to 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.

Note: See TracTickets for help on using tickets.