Re: Build Error on FreeBSD 12

On Fri, Nov 8, 2019 at 11:20 AM John Baldwin <[email protected]> wrote:

> On 10/30/19 11:41 AM, Joel Sherrill wrote:
> > Hi
> >
> > When building gdb 8.3 for *-rtems5 targets on FreeBSD 12, we are getting
> > undefined errors for libiconv symbols. The messages are like this:
> >
> > ================================
> >  CXXLD  gdb
> > charset.o: In function `convert_between_encodings(char const*, char
> const*,
> > unsigned char const*, unsigned int,
> > int, obstack*, transliterations)':
> > charset.c:(.text+0x251): undefined reference to `libiconv_open'
> > charset.c:(.text+0x2df): undefined reference to `libiconv'
> > charset.c:(.text+0x434): undefined reference to `libiconv_close'
> > charset.c:(.text+0x486): undefined reference to `libiconv_close'
> > charset.o: In function `wchar_iterator::wchar_iterator(unsigned char
> > const*, unsigned int, char const*, unsigned
> >  int)':
> > charset.c:(.text+0x4f9): undefined reference to `libiconv_open'
> > ================================
> >
> > Q1: The compile line is shortened in the output so I can't tell what it
> is
> > linking command is really doing. What's the magic for having the full
> > command lines printed?
> >
> > Q2: Does this sound familiar to anyone? We build fine on other OSes and
> > apparently this
> > doesn't happen on FreeBSD 11. Any hint is appreciated.
> >
> > The config.log does show it found iconv().
>
> Hmm, I haven't had a bare ./configure work on FreeBSD for quite some time
> as it doesn't add the needed -L /usr/local/lib for libiconv even though
> the configure scripts figure out that it needs -I /usr/local/include.
> However, that was true for me on older releases, not just 12.  The FreeBSD
> port (and my own build scripts for doing gdb work) work around this by
> defining LDFLAGS="-L /usr/local/lib" in the environment when invoking
> ./configure, e.g.:
>
> env LDFLAGS="-L /usr/local/lib" ./configure
>

Thanks. I can try that by hand next week.

Do you think this is a bug in the gdb configure magic?

I would really prefer to fix this properly.

--joel
RTEMS


>
> --
> John Baldwin
>