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

[Jeff Mayes]

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

[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.

[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.

[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

[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

[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

[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.

[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

[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

[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.

2. 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.

[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

[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?

[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.

[Joel Sherrill]

The only response I got on the gdb list said the person manually overrode where libiconv was located. I can't seem to find that email now. The autoconf is broken, known broken, ...

I have no idea why this works for others. It is still broken as of my overnight build.

​https://lists.rtems.org/pipermail/build/2020-April/012863.html

If this works for others on FreeBSD 12, I would like to know how.

[Chris Johns]

I recently add this to for 12 ...

​https://git.rtems.org/rtems-source-builder/commit/source-builder/sb/freebsd.py?id=599c4d7c87fab531014a614f2a32b56be0a3ce28
​https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/freebsd.py#n113

Is there an issue on 12 with this?

[Joel Sherrill]

The failure per ​https://lists.rtems.org/pipermail/build/2020-April/012863.html (sparc) and ​https://lists.rtems.org/pipermail/build/2020-April/012855.html (riscv) is in sis. I have no idea is this is before or after where gdb would be built and trip the iconv issue. Looks like a separate issue.

checking whether make sets $(MAKE)... yes
checking build system type... x86_64-pc-freebsd12.1
checking host system type... x86_64-pc-freebsd12.1
checking for x86_64-freebsd12.1-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sis-2.21-x86_64-freebsd12.1-1/sis-2.21':
configure: error: C compiler cannot create executables
See `config.log' for more details
shell cmd failed: /bin/sh -ex  /usr/home/joel/rtems-cron-5/rtems-source-builder/rtems/build/sis-2.21-x86_64-freebsd12.1-1/do-build
error: building sis-2.21-x86_64-freebsd12.1-1
  See error report: rsb-report-sis-2.21-x86_64-freebsd12.1-1.txt
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

[Chris Johns]

Are you building gdb with gcc and not cc?

[Joel Sherrill]

I have uninstalled GCC on our test machine. That seems to have resolved this.

How do we want to account for, document, and check this?

[Chris Johns]

I have updated the documentation. There was another ticket for that task.